<div dir="ltr"><div dir="ltr"><p>Hi,</p><p>I have the following setup:</p><p> - Wireguard server running Ubuntu 19.10<br> - Wireguard server physical network interface ens32 @ 192.168.122.236<br> - Wireguard server virtual network interface wg0 @ 192.168.200.254<br> - IP forwarding for ipv4 is enabled on Wireguard server<br> - Wireguard server is behind a NAT firewall<br> - wg0 on Wireguard server is brought up by 'wg-quick up wg0'</p><p> - Wireguard client running Ubuntu Linux Mint 19.3<br> - Wireguard client physical network interface enp5s0 @ 192.168.60.66<br> - Wireguard client virtual network interface wg0 @ 192.168.200.20<br> - Wireguard client is behind a NAT firewall<br> - wg0 on Wireguard client is brought up by 'wg-quick up wg0'</p><p>The client connects to the server without any problems. From the Wireguard client machine (labeled: A) I ping a machine (labeled: B) on the network where the Wireguard server is located. IP address of B is 192.168.122.20. My ping request on A get ping response from B, so everything is OK. If I use tcpdump to view traffic I get the following on Wireguard server:</p><p>$tcpdump -n -i wg0<br>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode<br>listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes<br>15:21:27.613387 IP 192.168.200.20 > <a href="http://192.168.122.20">192.168.122.20</a>: ICMP echo request, id 2621, seq 65, length 64<br>15:21:27.613503 IP 192.168.122.20 > <a href="http://192.168.200.20">192.168.200.20</a>: ICMP echo reply, id 2621, seq 65, length 64<br>15:21:28.615464 IP 192.168.200.20 > <a href="http://192.168.122.20">192.168.122.20</a>: ICMP echo request, id 2621, seq 66, length 64<br>15:21:28.615584 IP 192.168.122.20 > <a href="http://192.168.200.20">192.168.200.20</a>: ICMP echo reply, id 2621, seq 66, length 64</p><p><br>$tcpdump -n -i ens32<br>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode<br>listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes<br>15:25:04.970842 IP 192.168.122.236 > <a href="http://192.168.122.20">192.168.122.20</a>: ICMP echo request, id 2621, seq 282, length 64<br>15:25:04.970915 IP 192.168.122.20 > <a href="http://192.168.122.236">192.168.122.236</a>: ICMP echo reply, id 2621, seq 282, length 64<br>15:25:05.972827 IP 192.168.122.236 > <a href="http://192.168.122.20">192.168.122.20</a>: ICMP echo request, id 2621, seq 283, length 64<br>15:25:05.972911 IP 192.168.122.20 > <a href="http://192.168.122.236">192.168.122.236</a>: ICMP echo reply, id 2621, seq 283, length 64</p><p><br>I observe that the ping request (when viewed on ens32@Wireguard server) seems to originate from 192.168.122.236, that is the ip address of the Wireguard server physical network interface ens32. On wg0 (i.e. virtual interface on Wireguard server) the ping request seems to originate from 192.168.200.20 (i.e. virtual interface on Wireguard client). So when the packets are forwarded from wg0 to ens32 (and vice versa) their sender/destination IP seems to change. This is as far as I know named masquerading.</p><p>I do NOT have any PostUp/PostDown directives in my wg0.conf files (on either server or client). I have seen a lot of examples on the internet where PostUp/PostDown contains 'iptable rules' using MASQUERADE, but this is NOT something I use.</p><p>If I do (on Wireguard server) 'iptables -L -v -n' I get:<br>Chain INPUT (policy ACCEPT 7835K packets, 3459M bytes)<br> pkts bytes target     prot opt in     out     source               destination</p><p>Chain FORWARD (policy ACCEPT 4765K packets, 7815M bytes)<br> pkts bytes target     prot opt in     out     source               destination<br>5800K 2582M ACCEPT     all  --  wg0    *       <a href="http://0.0.0.0/0">0.0.0.0/0</a>            <a href="http://0.0.0.0/0">0.0.0.0/0</a></p><p>Chain OUTPUT (policy ACCEPT 8952K packets, 8660M bytes)<br> pkts bytes target     prot opt in     out     source               destination</p><p>So NO rules regarding masquerading seems to be in use.</p><p>----------------------------------------------------------<br>My question is:<br>If the change/translation in sender/destination IP address (described above) is due to masquerading, where is this masquerading rule set up? Is it done 'inside' the wg0 interface? Please explain who/what makes the instruction to change sender/destination IP address when packets are forwarded between wg0 and ens32 on the Wireguard server.<br>NOTE: There is NO problem, everything works fine but I would like to understand what is happening.<br>----------------------------------------------------------</p><p>Thank you very much!</p><p>BR,<br>Peter</p></div></div>