[strongSwan] Can't make routing work to pass Internet traffic

[Arab Abdulla]

Hello Phil,

> Client 1 send the packet addressed for 8.8.4.4, 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 8.8.4.4. How does the server know a packet for 8.8.4.4 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 8.8.4.4
8.8.4.4 via 10.10.3.1 dev ipsec2  src 10.10.2.1
    cache

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 > 8.8.4.4: 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 8.8.4.4", or perhaps "ip route get 8.8.4.4 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...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180504/5bc3a28d/attachment.html>