IP MASQUERADE (NAT)

OpenVPN Diagram

This diagram shows how OpenVPN creates a secure tunnel between remote devices and your local network.

Network Components

OpenVPN Server: IP 10.10.0.209 on LAN (10.10.0.0/24), 10.8.0.1 on TUN (10.8.0.0/24); handles routing and MASQUERADE-only NAT.
OpenVPN Client: Assigned 10.8.0.2 (or similar) in 10.8.0.0/24.
Gateway Router: 10.10.0.1, performs NAT for entire LAN → public IP.

Traffic Security

Encrypted VPN Tunnel (Red Dashed Line): Encrypted between client and server over internet.
Local Network Traffic (Green Dashed Line): Unencrypted within 10.10.0.0/24.
Physical Connections (White Solid Lines): Ethernet/WiFi links.

Routing Table (OpenVPN Server)

default via 10.10.0.1 dev enp6s18 onlink
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
10.10.0.0/24 dev enp6s18 proto kernel scope link src 10.10.0.209

IP forwarding is enabled.
No static routes pushed to LAN devices → they do not know about 10.8.0.0/24.

NAT Configuration (MASQUERADE Only)

sudo iptables -t nat -L -v -n
Chain POSTROUTING (policy ACCEPT)
 pkts  bytes target     prot opt in     out     source         destination
99896 8117K MASQUERADE  all  --  *      enp6s18 10.8.0.0/24    0.0.0.0/0

Only one rule:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp6s18 -j MASQUERADE

No SNAT, no DNAT, no PREROUTING rules → pure MASQUERADE.

How MASQUERADE Enables Bidirectional Communication

Even with only MASQUERADE, client ↔ LAN works unidirectionally:

Direction	Source → Dest	What Happens	Visible Source on LAN
Client → LAN	10.8.0.2 → 10.10.0.212	Packet arrives on `tun0` → kernel routes to `enp6s18` → MASQUERADE rewrites source to 10.10.0.209	10.10.0.209
LAN → Client	10.10.0.212 → 10.10.0.209	Reply comes back to server → conntrack remembers flow → reverse MASQUERADE restores dest to 10.8.0.2 → sent into `tun0`	N/A (reply)

Key Insight:
MASQUERADE is bidirectional via connection tracking (conntrack).
It does not require DNAT — the kernel automatically reverses the translation for reply packets.

Traffic Flow Example (from your `tcpdump`)

tun0  In  → 10.8.0.2  > 10.10.0.212   ICMP echo request
enp6s18 Out → 10.10.0.209 > 10.10.0.212   (MASQUERADE applied)
enp6s18 In  → 10.10.0.212 > 10.10.0.209   ICMP echo reply
tun0  Out → 10.10.0.212 > 10.8.0.2     (conntrack reverse translation)

Why LAN Cannot Initiate to Client

LAN host: ping 10.8.0.2
→ No route to 10.8.0.0/24
→ Packet goes to default gateway (10.10.0.1) → dropped or sent to internet

LAN hosts see clients as 10.10.0.209 — they cannot address 10.8.0.2 directly.

Summary: NAT Behavior with Only MASQUERADE

Traffic Type	Source Seen on LAN	Can Initiate?	NAT Type (Effective)
Client → LAN	10.10.0.209	Yes (client starts)	SNAT (via MASQUERADE)
LAN → Client	N/A	No	Reverse via conntrack
Client → Internet	10.10.0.209	Yes	MASQUERADE

Final Configuration Notes

Current Setup (Working for Client Access):

# Only this rule needed:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp6s18 -j MASQUERADE

# Plus:
echo 1 > /proc/sys/net/ipv4/ip_forward

To Allow LAN → Client (optional):

Add route on LAN devices:

route add -net 10.8.0.0/24 gw 10.10.0.209

Or use TAP mode + bridging (not recommended for security).

Conclusion

MASQUERADE alone is sufficient for client-initiated access to LAN and internet.
It performs effective SNAT + automatic reverse translation via conntrack.
No SNAT/DNAT rules needed — your single MASQUERADE rule is complete and correct.
LAN cannot reach clients — by design, due to no route to 10.8.0.0/24.

This is the standard, secure, minimal OpenVPN setup for remote access.