Hello, I have a VPN server (StrongSwan IPSEC, OpenVPN), where multiple peers have different network address translations (SNAT, DNAT, SNAT + DNAT) configured and it worked until recently, when after small reconfiguration one of the peers doesn't work properly. SNAT works but DNAT doesn't in general. For further analysis I chose a particular host pair. I can connect to 172.25.6.21 and the source address is rewritten to 100.64.104.5, but that host cannot connect to 100.64.104.129, which should DNAT to 10.0.10.12. When I tcpdump the traffic, I can only see 172.25.6.16/28 -> 100.64.104.129 [S], where normally it should be followed by 172.25.6.16/28 -> 10.0.10.12 [S]. xtables-monitor tracing shows that this packet matches the DNAT rule, but is discarded by the end of PREROUTING chain, having in fact its destination address untouched. At first, I wanted to check whether this packet is actually DNATted or not and came up with the following ruleset: pkts bytes target prot opt in out source destination 81 4124 DNAT tcp -- * * 172.25.6.16/28 100.64.104.129 to:10.0.10.12 0 0 RETURN all -- * * 172.25.6.16/28 10.0.10.12 0 0 RETURN all -- * * 172.25.6.16/28 100.64.104.129 And this got me to the conclusion written in the subject. Notice the packet counters - packet gets allegedly DNATted, but later matches neither original nor translated destination. What's important - there is one UDP service on my side, for which DNAT works (!) until the remote application using it gets restarted - then it doesn't (!!!). What I've tried: kernel update, reboot, rephrasing the rules to match different IPs, ports - to no avail. AFAIK other peers that we DNAT have no problems. # uname -a Linux hq-sitevpn 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux # iptables -V iptables v1.8.2 (nf_tables) strongswan: 5.7.2-1 -- Przemyslaw Kowalczyk
