[strongSwan] Can't make routing work to pass Internet traffic
noel.kuntze+strongswan-users-ml at thermi.consulting
Sat May 5 11:58:39 CEST 2018
The routing table is irrelevant here.
You need to configure leftsubnet and rightsubnet corresponding to your requirements, so the traffic you want to tunnel is permitted.
On 05.05.2018 04:58, Arab Abdulla wrote:
> Hello Phil,
>> Client 1 send the packet addressed for 22.214.171.124, 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 126.96.36.199. How does the server know a packet for 188.8.131.52 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 184.108.40.206
> 220.127.116.11 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 > 18.104.22.168: 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 22.214.171.124", or perhaps "ip route get 126.96.36.199 from 10.1.2.1 <http://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 --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Users