[strongSwan] Can't make routing work to pass Internet traffic
arab666 at protonmail.com
Sat May 5 04:58:52 CEST 2018
> Client 1 send the packet addressed for 188.8.131.52, and the server receives it. Now the server doesn't know about the routing tables on client 1: it only knows it has this packet addressed to 184.108.40.206. How does the server know a packet for 220.127.116.11 should go through client 2?
It seems it's the root of the problem. Why the server does not know? Why gateway is not used? My routing on client 1 is:
root at ubuntu1604:~# ip r g 18.104.22.168
22.214.171.124 via 10.10.3.1 dev ipsec2 src 10.10.2.1
So, IPSEC should incapsulate its destination and sends traffic to 10.10.3.1, is not it? But, instead, on server I see (49 is client 1 and 47 is server):
19:38:57.180893 IP 10.2.0.49.4500 > 10.2.0.47.4500: UDP-encap: ESP(spi=0xc3d23f24,seq=0xc), length 120
19:38:57.180981 IP 10.10.2.1 > 126.96.36.199: ICMP echo request, id 13060, seq 12, length 64
Where is my mistake? How should I re-configure it?
> You can check the server routing tables with "ip route get 188.8.131.52", or perhaps "ip route get 184.108.40.206 from 10.1.2.1: what's it say? Does it show the server thinks the next hop should be 10.1.3.1?
Still do not understand why no encapsulation in IPSEC and why server routing table matters.
> Reverse path filtering is another thing that can be a problem in scenarios like this, especially if client 1 has some IP address other than 10.1.2.1, and is not using 10.1.2.1 as the source address for the packets it sends destined for the internet. the log_martians and rp_filter sysctls are something to check. I've spent more than a few hours racking my brain as to why packets are "just disappearing" before remembering reverse path filtering.
I tried it before, not related.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users