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 
<[email protected]> 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@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.


Reply via email to