[Top] [All Lists]

Re: [RFC] MASQUERADE / policy routing ("Route send us somewhere else")

To: Harald Welte <laforge@xxxxxxxxxxxxx>
Subject: Re: [RFC] MASQUERADE / policy routing ("Route send us somewhere else")
From: Henrik Nordstrom <hno@xxxxxxxxxxxxxxx>
Date: Tue, 31 Aug 2004 12:24:34 +0200 (CEST)
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, rusty@xxxxxxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxxxxxx
In-reply-to: <>
References: <> <> <>
Sender: netdev-bounce@xxxxxxxxxxx
On Tue, 31 Aug 2004, Harald Welte wrote:

and it apparently happens in a lot of 'typical' setups where you have a
masqueraded DSL line with dynamic ip address for bulk traffic, and
fwmark-based routing through one or more tunnel interfaces, optionally
with different masqerading/SNAT.

Should only happen if the routing is screwed up, in principle..

Also, the MASQUERADE lookup (obviously) has no more saddr in the lookup,
that's another difference from the 'original' lookup.

This is a possible reason why it screws up for such many people? By not including the source IP you make the route lookup for determining the MASQUERADE information very different from the route lookup when forwardning the packet.

I think it would for most make more sense that the source IP assignment is based on routing using the original source address as key.

What I don't get is why MASQUERADE needs to do a route lookup at all. Isn't the traffic already routed at this point, and shouldn't it simply use the source IP of the current selected route or the interface primary IP of no source IP set in the route?

That is the presumption I am about to challenge.  Is the 'original'
interface really the one we want in this case?

If there is policy routing saying that packets with a given source should go out another interface my opinion is that they should.

I have been using SNAT in quite many complex routing setups and so far has not run into any situation where routing gets wrong in an unmanageable and unintuitive manner due to SNAT. MASQUERADE should not be more complex.


<Prev in Thread] Current Thread [Next in Thread>