DEV Community

ZeroTrust Architect
ZeroTrust Architect

Posted on • Originally published at cacheguard.com

Home VPN Server: NAT Traversal, DynDNS, Port Forwarding, and IKEv2 Under the Hood

#networking #security #linux #selfhosted

Running a VPN server at home puts the VPN endpoint on your home internet connection. This introduces specific technical challenges around NAT, port forwarding, and dynamic IP addressing that a datacenter deployment does not have. Here is how each one works.

Free VPN Server

The NAT problem

Home internet connections sit behind NAT. Your VPN server has a private IP (e.g., 192.168.1.10) and reaches the internet through the router's public IP (e.g., 203.0.113.1). VPN clients need to reach the server's public IP, not its private IP.

For IKEv2/IPsec:

  • UDP/500 — IKE_SA_INIT uses this port. The router must forward it to the VPN server.
  • UDP/4500 — NAT-Traversal (NAT-T). IKEv2 automatically detects NAT presence and switches from UDP/500 to UDP/4500 when NAT is detected between peers. UDP/4500 encapsulates ESP packets inside UDP, preventing NAT devices from mangling ESP (IP protocol 50) which they cannot track in connection tables.
  • ESP (IP protocol 50) — Not needed if NAT-T is used (which it will be, since the router is NAT). 
[VPN Client on internet]
        |
        | UDP/500 → IKE_SA_INIT (NAT detected)
        | UDP/4500 → IKE_AUTH + all ESP data
        ↓
[Router: NAT + port forward UDP/500,4500 → 192.168.1.10]
        |
        ↓
[VPN Server: 192.168.1.10]
Enter fullscreen mode Exit fullscreen mode

Router port forwarding config (example for iptables-based router):

# Forward IKE ports to VPN server
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 500 -j DNAT --to 192.168.1.10:500
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 4500 -j DNAT --to 192.168.1.10:4500
Enter fullscreen mode Exit fullscreen mode

Dynamic IP: the DynDNS mechanism

Most home ISPs assign dynamic public IPs — the IP can change after a router restart or on the ISP's rotation schedule. VPN clients need a stable hostname to connect to, not an IP.

DynDNS solves this: a DNS record (home.freemyip.com → 203.0.113.1) is updated automatically whenever the public IP changes.

The update mechanism uses a simple HTTP GET request to the DynDNS provider's API:

GET https://freemyip.com/update?token=YOUR_TOKEN&domain=yourhost.freemyip.com
Enter fullscreen mode Exit fullscreen mode

The VPN appliance polls its current public IP (via an external IP detection service or the router's API) and compares it to the last known IP. If changed, it fires the update request.

# Minimal DynDNS update script
CURRENT_IP=$(curl -s https://api4.ipify.org)
LAST_IP=$(cat /var/cache/last_public_ip 2>/dev/null)

if [ "$CURRENT_IP" != "$LAST_IP" ]; then
    curl -s "https://freemyip.com/update?token=${TOKEN}&domain=${DOMAIN}"
    echo "$CURRENT_IP" > /var/cache/last_public_ip
fi
Enter fullscreen mode Exit fullscreen mode

Run via cron every 5 minutes. DNS TTL should be set to 60–300 seconds so clients pick up the new IP quickly after a change.

IKEv2 reconnection after IP change

IKEv2 has a DPD (Dead Peer Detection) mechanism. When the server's IP changes, existing tunnels break — the client sends DPD probes to the old IP and gets no response. After the DPD timeout, the client marks the peer as dead and the IKE SA is torn down.

On reconnect, the client resolves the DynDNS hostname (which now points to the new IP) and establishes a new IKE_SA_INIT exchange.

# StrongSwan DPD config
dpdaction=restart     # Restart the tunnel on dead peer detection
dpddelay=30s          # Send DPD probe every 30s
dpdtimeout=120s       # Declare peer dead after 120s of no response
Enter fullscreen mode Exit fullscreen mode

Why the VPN server needs two network interfaces

A VPN server sitting at the network edge needs:

  • External interface (WAN): Connected to the router/modem, receives VPN client connections from the internet
  • Internal interface (LAN): Connected to the home network, routes decapsulated VPN traffic to local resources

With a single interface, VPN traffic and LAN traffic are on the same interface — routing conflicts arise and security zones cannot be enforced (VPN clients would be indistinguishable from local devices at the network layer).

The external interface gets the DNAT port forwards from the router. The internal interface connects to the LAN switch. The VPN server performs NAT between VPN clients (virtual IPs like 10.8.0.0/24) and the LAN.

CacheGuard handles all of this — DynDNS updates (freemyip.com and others), IKEv2 configuration, NAT rules, and client profile generation — through a single web interface.

→ https://www.cacheguard.com/free-vpn-server/

Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.

Top comments (0)