Re: 2.4.23 masquerading broken? key.oif = 0;

Re: 2.4.23 masquerading broken? key.oif = 0;

[Neal Stephenson]

Hi,
	I have this problem with 2.4.23. It is new problem, my setup was
working fine on 2.4.22 and 2.4.22-ac4. I tried the patch of moving
key.oif=0 without success. The problem occurs as soon as the machine
comes up.

	I use the iproute tools with rules and tables and mark packets with
iptables so that port 80 traffic goes out through ppp0 rather than the
default eth1. ppp0 has another iptable rule that masquerades everything.
I see the packet enter through eth0 and it never reaches another
interface, at least as far as I can tell with tcpdump. A brief
description of my network is eth0 is my local network, ppp0 is my
personal high speed, and eth1 is my permanent DSL connection. 


	I can send my .config or routing tablef if wanted. The brief is

CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_NAT=y

	along with ip netfilter essentially all modules. Some relevant iptable
and ip commands

iptables -t mangle -A PREROUTING --protocol tcp --destination-port 80 -j
MARK --set-mark 0x932
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

ip rule add pri 424 iif eth0 fwmark 0x932 table symp

	and this is what shows up in dmesg

MASQUERADE: Route sent us somewhere else.

	Any suggestions appreciated,

		Neal

Re: 2.4.23 masquerading broken? key.oif = 0;

[Martin Josefsson]

On Tue, 9 Dec 2003, Neal Stephenson wrote:

> iptables -t mangle -A PREROUTING --protocol tcp --destination-port 80 -j
> MARK --set-mark 0x932
> iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
>
> ip rule add pri 424 iif eth0 fwmark 0x932 table symp
>
> 	and this is what shows up in dmesg
>
> MASQUERADE: Route sent us somewhere else.
>
> 	Any suggestions appreciated,

Try adding "-i eth0" to the mangle/PREROUTING rule
and remove "iif eth0" in the iproute rule.

I think the problem is that when the packet is routed it follows the
iproute rule and goes to the "symp" table.
But when ipt_MASQUERADE.c does another lookup to get the local
source-address of the route that this packet will match we don't have the
input-interface anymore, and thus matches another rule/route. So change
the fwmark to include the input interface.

This is just a theory, I know too little about your routingtables to say
anything more specific.

(The earlier behaviour was incorrect, ipt_MASQUERADE.c ignored
policy-routing which broke things. Now it should be a lot more sane, but
does unexpected things in some cases, like yours :)

/Martin

Re: 2.4.23 masquerading broken? key.oif = 0;

[Neal Stephenson]

Unfortunately this did not work it produces the same effect. The changes
do work fine in 2.4.22-ac4, so the changes do work and make sense, don't
know why i didn't do it that way the first time.

Neal

On Wed, 2003-12-10 at 05:04, Martin Josefsson wrote:
> On Tue, 9 Dec 2003, Neal Stephenson wrote:
> 
> > iptables -t mangle -A PREROUTING --protocol tcp --destination-port 80 -j
> > MARK --set-mark 0x932
> > iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
> >
> > ip rule add pri 424 iif eth0 fwmark 0x932 table symp
> >
> > 	and this is what shows up in dmesg
> >
> > MASQUERADE: Route sent us somewhere else.
> >
> > 	Any suggestions appreciated,
> 
> Try adding "-i eth0" to the mangle/PREROUTING rule
> and remove "iif eth0" in the iproute rule.
> 
> I think the problem is that when the packet is routed it follows the
> iproute rule and goes to the "symp" table.
> But when ipt_MASQUERADE.c does another lookup to get the local
> source-address of the route that this packet will match we don't have the
> input-interface anymore, and thus matches another rule/route. So change
> the fwmark to include the input interface.
> 
> This is just a theory, I know too little about your routingtables to say
> anything more specific.
> 
> (The earlier behaviour was incorrect, ipt_MASQUERADE.c ignored
> policy-routing which broke things. Now it should be a lot more sane, but
> does unexpected things in some cases, like yours :)
> 
> /Martin