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@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.
signature.asc
Description: OpenPGP digital signature
