What are the correct iptables rules for an ipsec site to site?

I am trying to configure an IPSEC site to site using strongswan on Debian 12. The VPN is UP, as shown below Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.1.0-30-cloud-amd64, x86_64): uptime: 18 hours, since Jan 22 14:58:17 2025 malloc: sbrk 2125824, mmap 0, used 1366096, free 759728 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5 loaded plugins: charon aesni aes rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs12 pgp dnskey sshkey pem openssl pkcs8 fips-prf gmp agent xcbc hmac kdf gcm drbg attr kernel-netlink resolve socket-default connmark forecast farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock unity counters Listening IP addresses: Connections: server: ... IKEv2, dpddelay=30s server: local: [] uses pre-shared key authentication server: remote: [] uses pre-shared key authentication server: child: === TUNNEL, dpdaction=start Security Associations (1 up, 0 connecting): server: ESTABLISHED 2 hours ago, []...[] server: IKEv2 SPIs: , pre-shared key reauthentication in 4 hours server: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 server{27}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: server{27}: AES_CBC_128/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 42 minutes server{27}: === But I believe I am having issues configuring the correct IPTables rules. I tried following the recommendations shown here , as well as the steps from multiple tutorials (I reached page 2 of google). I have route to the client VPN range dev vti0 scope link The interface is UP 4: vti0@NONE: mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000 link/ipip peer inet6 /64 scope link valid_lft forever preferred_lft forever What I noticed is: when I configure an snat to translate the VPN traffic going out my vti interface, the traffic does not reach the interface, as the TCPDump cannot capture anything. Any other rule (or no rule at all), I get traffic in the TCPDump tcpdump -i vti0 -n tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on vti0, link-type RAW (Raw IP), snapshot length 262144 bytes 13:41:14.939880 IP .43140 > .22: Flags [S], seq 3230932500, win 64800, options [mss 1440,sackOK,TS val 2922516277 ecr 0,nop,wscale 7], length 0 13:41:15.942056 IP .43140 > .22: Flags [S], seq 3230932500, win 64800, options [mss 1440,sackOK,TS val 2922517280 ecr 0,nop,wscale 7], length 0 But get the errors "No route to host" when trying to access a server that I know is available on the other site. I understand that the issue with "no route to host" **could be** that the IP of my outbound traffic is using my internal IP and not one on my VPN range, but as I explained before, once I apply SNAT, the traffic stops and I get a timeout in the connection. A few of the rules I tried applying (not all at the same time, of course) iptables -A FORWARD -i eth0 -o vti0 -j ACCEPT iptables -A FORWARD -i vti0 -o eth0 -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -d -j SNAT --to-source iptables -t nat -A POSTROUTING -o vti0 -j MASQUERADE iptables -t nat -A POSTROUTING -o eth0 -s -j SNAT --to-source iptables -t nat -A POSTROUTING -o vti0 -d -j SNAT --to-source iptables -t nat -A POSTROUTING -o vti0 -d 0.0.0.0/0 -j SNAT --to-source iptables -t nat -A POSTROUTING -s -d -J MASQUERADE iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT iptables -t nat -A POSTROUTING -o vti0 -m policy --dir out --pol ipsec -j ACCEPT iptables -t mangle -A FORWARD -m policy --pol ipsec --dir in -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360 iptables -t mangle -A FORWARD -m policy --pol ipsec --dir out -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360 iptables -t nat -A POSTROUTING -o vti0 -d -j SNAT --to-source iptables -t nat -A POSTROUTING -o eth0 -d -j SNAT --to-source iptables -t nat -A POSTROUTING -s -o vti0 -m policy --dir out --pol ipsec -j ACCEPT iptables -t nat -A POSTROUTING -s -o vti0 -j MASQUERADE iptables -t nat -A POSTROUTING -o vti0 -j SNAT --to-source iptables -t nat -A POSTROUTING -o vti0 -j SNAT --to-source iptables -t nat -A POSTROUTING -s -o vti0 -m policy --dir out --pol ipsec -j ACCEPT iptables -t nat -A POSTROUTING -s -o eth0 -j MASQUERADE iptables -t nat -A POSTROUTING -o vti0 -j SNAT --to-source iptables -t nat -A POSTROUTING -d -j ACCEPT iptables -t mangle -A OUTPUT -d -j MARK --set-mark 1 iptables -t nat -A POSTROUTING -m mark --mark 1 -j SNAT --to-source iptables -t nat -A POSTROUTING -o vti0 -s -d -j SNAT --to-source iptables -t nat -A POSTROUTING -o vti0 -s -d -j SNAT --to-source I don't know whether is relevant, but my server is in Azure, with IP forwarding enabled both in Azure and in Debian. There's no outbound rules in Azure.