Blog

Deploying Self-hosted WireGuard VPN on AWS, Azure & GCP

Architectural guide to running Tunnex Zero Trust gateways across EC2, Azure VMs, Compute Engine, and Kubernetes with zero SaaS lock-in.

· Tunnex Team · 3 min read

Modern engineering teams run infrastructure across multiple public clouds and private data centers. Wiring secure private connectivity between an AWS VPC, an Azure VNet, a Google Cloud Compute Engine instance, and on-premises Kubernetes clusters traditionally required expensive IPsec hardware appliances, BGP routing complexities, or proprietary SaaS overlay networks that route your sensitive data through third-party servers.

With Tunnex, you can establish kernel-level WireGuard site-to-site tunnels and Zero Trust access across any cloud provider — self-hosted entirely on infrastructure you run.

Core Deployment Architecture

Tunnex decouples the Control Plane (policy distribution and identity enrollment) from the Data Plane (WireGuard packet processing).

                      +-----------------------------+
                      |   Self-Hosted Control Plane |
                      +--------------+--------------+
                                     | (policy & keys)
              +----------------------+----------------------+
              |                      |                      |
    +---------v---------+  +---------v---------+  +---------v---------+
    |    AWS VPC EC2    |  |    Azure VNet VM  |  |    GCP Compute    |
    |  Tunnex Gateway   |  |  Tunnex Gateway   |  |  Tunnex Gateway   |
    +---------+---------+  +---------+---------+  +---------+---------+
              |                      |                      |
              +======================+======================+
                     Direct WireGuard Site-to-Site Mesh

1. Amazon Web Services (AWS VPC & EKS)

Deploying a Tunnex Gateway on AWS involves launching a standard Linux EC2 instance (such as t4g.small or t3.micro) inside your target VPC or running the Tunnex Kubernetes Operator inside an EKS cluster.

  • UDP Port Binding: Expose UDP port 51820 on your Security Group to allow peer-to-peer WireGuard handshakes.
  • IP Forwarding: Enable net.ipv4.ip_forward=1 in sysctl for gateway routing across private VPC subnets.
  • Auto-Enrollment: Run tunnexd enroll --token <REGISTRATION_TOKEN> to automatically generate peer keys and fetch security policies.

2. Microsoft Azure (VNet & AKS)

In Azure, Tunnex runs inside any Linux Virtual Machine or AKS pod. Because Tunnex operates as a native WireGuard kernel module (wireguard.ko), packet processing occurs at line rate without user-space context switches.

  • Network Security Group (NSG): Add an inbound security rule allowing UDP traffic on port 51820.
  • VNet Subnet Routing: Add a custom route table entry directing your internal subnet CIDRs (10.2.0.0/16) to the Tunnex Gateway VM’s private IP.

3. Google Cloud Platform (GCP Compute Engine & GKE)

On Google Cloud, Tunnex integrates natively with Compute Engine VPC networks and Google Kubernetes Engine (GKE).

  • Firewall Rules: Create a VPC firewall rule allowing udp:51820 from target remote peer CIDRs.
  • Can IP Forward: Enable canIPForward: true on the Compute Engine instance metadata when serving as a gateway for entire VPC subnets.

Why Kernel-Level WireGuard Site-to-Site Peering?

  1. Default-Deny Security: All traffic is blocked by default until an explicit identity policy or subject rule permits flow.
  2. Zero SaaS Relay: Packets travel directly between your cloud gateways. Your private data never touches Tunnex servers or third-party relays.
  3. Deterministic NFTables State: Access policies compile directly into kernel nftables rules on each gateway, eliminating latency overhead.

To learn more about setting up your first gateway, check out the Tunnex Quickstart Guide or read about our Zero Trust Architecture.