netdev
[Top] [All Lists]

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

To: Netfilter Development Mailinglist <netfilter-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [RFC] MASQUERADE / policy routing ("Route send us somewhere else")
From: Harald Welte <laforge@xxxxxxxxxxxxx>
Date: Mon, 30 Aug 2004 22:19:57 +0200
Cc: Rusty Russell <rusty@xxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
Mail-followup-to: Harald Welte <laforge@xxxxxxxxxxxxx>, Netfilter Development Mailinglist <netfilter-devel@xxxxxxxxxxxxxxxxxxx>, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040722i
Hi!

Apparently a lot of people still have issues when combining MASQUERADE
and policy routing.  

In those cases, the error path from net/ipv4/netfilter/ipt_MASQUERADE.c:

                if (rt->u.dst.dev != out) {
                        if (net_ratelimit())
                                printk("MASQUERADE:"
                                       " Route sent us somewhere else.\n");
                        ip_rt_put(rt);
                        return NF_DROP;
                }

is taken.

A couple of questions:

1) Why do we have this check in the first place?  What would be wrong
   with re-routing if the user requests us by configuration?

2) Why don't we include 'oif' in the routing key?  If we wanted to make
   sure that oif doesn't change, then we should tell the routing lookup
   rather than complaining afterwards, shouldn't we ?

I think the current code makes it hard (if not impossible?) for the
system adminsitrator to get it right (for no apparent reason to me).

Comments, anyone?
-- 
- 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>