RE: [PATCH] xt_gateway match

[Amin Azez <azez@ufomechanic.net>]

Sorry for the horrible quoting style, pocket outlook is nasty, and the hermes linux port isn't progressed enough for me to switch...

Thanks for looking at this, Jan. I'm away from a testing box right now, but I think you got a test wrong. The gateway test is meant to exclude cases where the neighbour table matches AND the daddr matches, because that means the packet wasn't routed to that target AS a gateway.

For nexthop we don't want to match daddr regardless, only if it is also matching the neighbor table.

Gateway: match neighbourtable and not match daddr
Nexthop: match neighbour table.

Note: if --gateway is used, a downstream snat'd network can't ping the gateway (no math, no snat) but can ping beyond the gateway.

Sam
-----Original Message-----
From: "Jan Engelhardt" <jengelh@linux01.gwdg.de>
To: "Amin Azez" <azez@ufomechanic.net>
Cc: netfilter-devel@lists.netfilter.org
Sent: 02/06/07 17:56
Subject: [PATCH] xt_gateway match
...
+               info->flags ^= info->flags & IPT_GATEWAY_ROUTE;                 

Stunning line.

So, I refreshed this to be xtables-style, xt_gateway. It builds cleanly,
but only done limited testing on it yet. Especially, I decoupled that
bigass return statement to make it easier to read. I hope I got all the
conditions right.

How things look:
 inet 192.168.222.36/24
 default gw 192.168.222.1

What I did:
 iptables -A OUTPUT -m gateway --gateway 192.168.222.1
 iptables -A OUTPUT -m gateway --nexthop 192.168.222.1
 ping -c1 192.168.222.1
 iptables -nvL
    +1 for the --gateway rule
    +1 for the --nexthop rule
 ping -c1 134.76.13.21
    +1 for the --gateway rule
    +0 for the --nexthop rule

Route to 134.76.13.21 is:
   (192.168.222.36)
    192.168.222.1
    10.10.96.1
    134.76.63.254
    134.76.13.21

Does xt_gateway still do the right thing? Please check, thanks!

(patches as a response to this mail,
or svnized for now @ 
https://dev.computergmbh.de/svn/misc_kernel/xt_gateway/trunk/ )


	Jan
--