netdev
[Top] [All Lists]

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

To: "David S. Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: [RFC] MASQUERADE / policy routing ("Route send us somewhere else")
From: Harald Welte <laforge@xxxxxxxxxxxxx>
Date: Tue, 31 Aug 2004 03:38:42 +0200
Cc: netfilter-devel@xxxxxxxxxxxxxxxxxxx, rusty@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20040830140729.7309ecc0.davem@xxxxxxxxxxxxx>
Mail-followup-to: Harald Welte <laforge@xxxxxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, netfilter-devel@xxxxxxxxxxxxxxxxxxx, rusty@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
References: <20040830201957.GY5824@xxxxxxxxxxxxxxxxxxxxxxx> <20040830140729.7309ecc0.davem@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040722i
Thanks for your quick reply, Dave.

On Mon, Aug 30, 2004 at 02:07:29PM -0700, David S. Miller wrote:

> The original idea was that if the input route relookup sends us
> to a different device, something is very strange.
> 
> Input routing looks up using daddr/saddr/tos as the key.  The change
> here is that we're now using the fwmark, so you're right that only
> policy routing can cause this thing to trigger.

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.

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

> Where did this check some from?  From this change below, and the
> changelog explains why we do things this way.
> 
> I know you don't use BK Harald, but things like this are why you should
> at least use the web based interface to look at file change history.

Thanks Dave, I did look up the bk web interface on this item before sending
this post ;) However

> # It can screw up the things a lot. 

does not really give me an understanding of why and where it might screw
up. I really want  to fully understand this issue before proposing any
change.

> # In this context, if you want to be sure that packet will go out
> # expected interface you do plain lookup and drop packet if it gave
> # you some strange route.

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

I've seen a number of users commenting out that check or even starting
to use the iptables ROUTE target (ugly) to get it working in their
setup.  Or they start to use SNAT with scripts in PPP if-up to update
the ruleset with the new dynamic IP :(

-- 
- Harald Welte <laforge@xxxxxxxxxxxxx>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

Attachment: signature.asc
Description: Digital signature

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