Understand forwarding, NAT, and egress

A VPN endpoint that routes traffic between interfaces acts as a gateway. Packets arrive on wg0 and need to leave through eth0. By default, Linux refuses to do that — it behaves as a host, not a router. The operating system must permit IP forwarding:

sudo sysctl -w net.ipv4.ip_forward=1
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf

The first command applies the setting now. The second makes it survive reboots.

Forwarding alone is not enough for Internet egress. Think about the packet the client sends: its source address is 10.14.0.2, a private address. The web server’s reply, addressed to 10.14.0.2, would be dropped by the first Internet router that saw it. There is no return path.

So for Internet egress, the gateway often replaces the client source address with its own public address. This is source NAT, commonly implemented with masquerading:

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Every packet leaving through eth0 now carries the server’s address. Replies return to the gateway, which maps them back to the VPN client using its connection-tracking table. The rewriting is invisible to both ends.

Verify the whole chain from the client:

curl https://ifconfig.me
# 203.0.113.10   ← the gateway's public address, not yours

Private-network access is a different story. If the office network knows a route back to 10.14.0.0/24, no address rewriting is needed. Real routes carry traffic in both directions. Prefer routing when both sides can learn the return path: destination logs keep real client addresses, and you carry no NAT state that can fill up or expire mid-connection.

The classic failure: the handshake works, pinging the gateway’s 10.14.0.1 works, and nothing beyond it responds. That pattern almost always means forwarding is off or the masquerade rule vanished — iptables rules do not survive reboots unless you persist them. Check sysctl net.ipv4.ip_forward and iptables -t nat -L POSTROUTING -n before touching anything else.