Re: Wrong routing when combining ip rule with SNAT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Vigneswaran R a écrit :
> Hello Nikolaus,
> 
> I have a doubt. It seems, rath of ebox is assigned with IP address in 
> the range 192.168.12.0/24. However, IP address of vostro seems to be 
> 192.168.17.47 (assuming /24). Ebox doesn't have any route to this range. 
> So it try to use default route via eth0.

Correct.

> What I assume is, 'vostro' has IP addresses in (atleast) two ranges 
> (192.168.12.0/24, 192.168.17.0/24). In the default routing table, the 
> src IP is set to 192.168.12.x (for the packets originating from vostro). 
> However, the 'tovpn' table didn't specify the src IP. So, when the 
> 'tovpn' table is being used, the packets may have got the src IP as 
> 192.168.17.x.
> 
> I think, you can avoid this by explicitly specifying the src IP when 
> adding the route to 'tovpn' table,
> 
>      ip route add default via 192.168.12.1 src 192.168.12.x table tovpn

This won't work. It's too late. The source address has already been
selected by the TCP layer when the packet was created and won't be
changed when the packet is re-routed due to the mark.

Possible workarounds :
- Add a route on ebox to let it know that 192.168.17.47 is reachable
through rath. My favourite choice.
- Use SNAT to the address of the output interface on vostro.
- Use connection mark (connmark) by iptables on ebox so that replies to
original packets received on a given interface are forwarded to the same
interface.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux