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

[Noel Kuntze]

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 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 <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...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180505/1b5ab724/attachment.sig>