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

[Arab Abdulla]

It's configured 0.0.0.0/0 everywhere.


​Sent with ProtonMail Secure Email.​

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On May 5, 2018 2:58 PM, Noel Kuntze <noel.kuntze+strongswan-users-ml at thermi.consulting> wrote:

> 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.