I wasn’t planning to write a dedicated post about NAT — because in most situations, it’s simply not needed.
But when I was learning WireGuard myself, I ran into a flood of tutorials that used NAT without explaining why. Instead of helping, they often created confusion. After reviewing many of these setups, I realized NAT was being applied unnecessarily — sometimes even interfering with how WireGuard is supposed to work.
What’s Important?
The most critical concept to understand is AllowedIPs. This single setting controls both routing and access in WireGuard.
- For outgoing traffic: the destination IP must match an entry in
AllowedIPs. - For incoming traffic: the source IP must match an entry in
AllowedIPs.
Because of this, AllowedIPs must be carefully mirrored on both peers. Whether you like this design or not, you cannot override or bypass it using traditional routing or NAT techniques.
So, Why NAT at All?
The most commonly used form of NAT is source NAT (SNAT) with port overloading — also known as masquerading. This is the default in most home routers, where private IPs (e.g., 192.168.1.x) are translated into a single public IP from the ISP.
If you have multiple peers using the same subnet, you can’t include them all in AllowedIPs — because their addresses will conflict. In such cases, NAT becomes useful. You can masquerade each peer’s LAN behind a unique WireGuard tunnel IP (like 10.x.x.x), allowing communication without exposing overlapping LANs.
Another practical case is when you want to send the LAN’s internet traffic through the WireGuard tunnel to the server — for example, to route internet access through a central location. In this setup, masquerading ensures that outbound packets are properly routed through the tunnel and back.
Also, just like traditional NAT, this breaks inbound connections. But in some cases, that’s a feature — a form of implicit security. If you don’t want to expose your LAN to the server side, masquerading is a valid solution.
NAT Implementation Example
Let’s reuse the topology from Part 1 or Part 2, where the server-side LAN is 172.19.2.0/24.
Now, say the client has a LAN subnet 192.168.8.0/24, but you don’t want to expose that network to the server — or you want to route LAN traffic to the internet via the server, or another peer already has the same subnet. Here’s what to do:
-
Do not include
192.168.8.0/24in the server’sAllowedIPs. - On the client side, masquerade LAN traffic behind the WireGuard tunnel IP (e.g.,
10.52.53.7) with this command:
iptables -t nat -A POSTROUTING -s 192.168.8.0/24 -o wg0 -j MASQUERADE
This ensures the server sees all packets as coming from 10.52.53.7, not from the internal LAN (192.168.8.x).
Verifying on the Client
To confirm the NAT rule is active, inspect the POSTROUTING chain:
root@vpn-client:~# iptables -t nat -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
20 1688 MASQUERADE all -- * wg0 192.168.8.0/24 0.0.0.0/0
Final Thoughts
WireGuard is clean and predictable — but only if you understand AllowedIPs and don’t blindly apply NAT.
Top comments (4)
The problem with wireguard is that even if you do the NAT, it will be ignored. The Table=auto mode simply routes the packets you specified in AllowedIps into the wireguard network interface. And once the packets is in the network interface, wireguard uses its simple longest prefix match to find the destination peer. Any linux based routing you apply, will change the packet BEFORE it reaches the wireguard interface. There is no way to change the routing algorithm once the packet is inside the network interface.
github.com/WireGuard/wireguard-lin...
You can check the code yourself, they simply use AllowedIps to match peer. Even if you somehow NATed your packet, it will not matter after it reaches the wireguard's interface.
I have tried playing arround with mangle, fwmark, but all that is ignored by the wireguard interface. It does not care about your linux routing, and you can not customize wireguard's internal routing algorithm. Once packet is in the wg0, it is simply matched by the algorithm above.
The only way to avoid that is to spawn wireguard interface per client you want to have custom routing with.
Our usecase was creating tailscale subnet alternative, to avoid all the magic and complexity of mesh networks like tailscale, nebula, Netmaker I tried using simple wireguard setup.
Right now my setup is custom IPAM using postgres + python script using pyroute2 to apply all the NAT rules on server side + automated peer interface management.
This one could be better explained. kind of getting what you are trying to say. what others are doing wrong with NAT for ex. Thx anyway much appreciated.
I truly appreciate your feedback. I’m still new to writing, this was only my third blog. I know there’s plenty of room to improve. I’ll definitely keep your point in mind for next time. I’m planning my fourth post on WireGuard, maybe something around routing and I’m open to suggestions if there's a topic you'd like to see covered.