[Top] [All Lists]

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

To: davem@xxxxxxxxxxxxx (David S. Miller)
Subject: Re: [RFC] MASQUERADE / policy routing ("Route send us somewhere else")
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 31 Aug 2004 12:32:40 +1000
Cc: laforge@xxxxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxxxxxx, rusty@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, kuznet@xxxxxxxxxxxxx
In-reply-to: <>
Organization: Core
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686))
David S. Miller <davem@xxxxxxxxxxxxx> wrote:
> Good question.
> What Alexey appears to be objecting to, exactly, is how Rusty added
> a specific output device specifier to the flow key for route lookup.
> I think the check can be removed.  If someone screams, we'll revisit.

I don't think removing the check fixes the problem.  If the route
does go to a different interface the source address may be completely
bogus for the original packet.

This is what happens:

* Forwarded packet is routed to iface1.
* Packet hits MASQUERADE.
* Routing lookup returns iface2 with different source address.

So if iface2's source address is not valid when the packet leaves on
iface1, then the packet won't go very far.

If you're wondering why the second lookup is returning a different
interface at all, it's because the routing lookup in MASQUERADE is
done as if the packet was generated by localhost.  This is obviously
going to differ from the normal routing lookup if the packet was

The most common scenario for this is multiple nexthops in your
default route.  The first lookup will return iface1, but the
second lookup may return a different nexthop.

As it stands that packet is dropped which is no good.  But removing
the check just sends the packet out of iface1 with iface2's address
which isn't much better depending on your ISP's filtering policy.

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page:
PGP Key:

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