Translation of sender IP address

[tubi webmail]

Hi,

I have the following setup:

 - Wireguard server running Ubuntu 19.10
 - Wireguard server physical network interface ens32 @ 192.168.122.236
 - Wireguard server virtual network interface wg0 @ 192.168.200.254
 - IP forwarding for ipv4 is enabled on Wireguard server
 - Wireguard server is behind a NAT firewall
 - wg0 on Wireguard server is brought up by 'wg-quick up wg0'

 - Wireguard client running Ubuntu Linux Mint 19.3
 - Wireguard client physical network interface enp5s0 @ 192.168.60.66
 - Wireguard client virtual network interface wg0 @ 192.168.200.20
 - Wireguard client is behind a NAT firewall
 - wg0 on Wireguard client is brought up by 'wg-quick up wg0'

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:

$tcpdump -n -i wg0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
15:21:27.613387 IP 192.168.200.20 > 192.168.122.20: ICMP echo request, id
2621, seq 65, length 64
15:21:27.613503 IP 192.168.122.20 > 192.168.200.20: ICMP echo reply, id
2621, seq 65, length 64
15:21:28.615464 IP 192.168.200.20 > 192.168.122.20: ICMP echo request, id
2621, seq 66, length 64
15:21:28.615584 IP 192.168.122.20 > 192.168.200.20: ICMP echo reply, id
2621, seq 66, length 64


$tcpdump -n -i ens32
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes
15:25:04.970842 IP 192.168.122.236 > 192.168.122.20: ICMP echo request, id
2621, seq 282, length 64
15:25:04.970915 IP 192.168.122.20 > 192.168.122.236: ICMP echo reply, id
2621, seq 282, length 64
15:25:05.972827 IP 192.168.122.236 > 192.168.122.20: ICMP echo request, id
2621, seq 283, length 64
15:25:05.972911 IP 192.168.122.20 > 192.168.122.236: ICMP echo reply, id
2621, seq 283, length 64


I observe that the ping request (when viewed on ens32 at 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.

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.

If I do (on Wireguard server) 'iptables -L -v -n' I get:
Chain INPUT (policy ACCEPT 7835K packets, 3459M bytes)
 pkts bytes target     prot opt in     out     source
destination

Chain FORWARD (policy ACCEPT 4765K packets, 7815M bytes)
 pkts bytes target     prot opt in     out     source
destination
5800K 2582M ACCEPT     all  --  wg0    *       0.0.0.0/0
0.0.0.0/0

Chain OUTPUT (policy ACCEPT 8952K packets, 8660M bytes)
 pkts bytes target     prot opt in     out     source
destination

So NO rules regarding masquerading seems to be in use.

----------------------------------------------------------
My question is:
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.
NOTE: There is NO problem, everything works fine but I would like to
understand what is happening.
----------------------------------------------------------

Thank you very much!

BR,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20200226/0796062e/attachment.html>