[PATCH] xt_gateway match

[PATCH] xt_gateway match

[Jan Engelhardt]

On Jun 1 2007 17:47, Amin Azez wrote:
>
>This adds a gateway match to iptables that lets you match against the
>routed ipv4 gateway, it's very useful for SNAT if you want to avoid
>replicating your routing in your SNAT table.
>
>e.g.
>
>iptables -t nat -A POSTROUTING -m gateway --nexthop 172.16.1.1 -j SNAT
>--to-address 172.16.1.5
>iptables -t nat -A POSTROUTING -m gateway --nexthop 192.168.1.1 -j SNAT
>--to-address 192.168.1.25
>
>The .gateway-test doesn't work for me because I don't build into my
>kernel source dir, but I tried to do it right for a public release.

(Neither do I, just run `KERNEL_DIR=/ws/linux-2.6.22-rc3 make` in the
iptables directory.)

+               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
-- 

RE: [PATCH] xt_gateway match

[Amin Azez]

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
-- 

RE: [PATCH] xt_gateway match

[Jan Engelhardt]

On Jun 4 2007 11:14, Amin Azez wrote:
>
>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.

Ok I am a bit narrow on this, anyway, I checked again and it looks like, 
yes, there was something wrong. I fixed it to:

	if (memcmp(&info->gateway, &neigh->primary_key, tbl->key_len) != 0)
		return false;
	if (!(info->flags & XT_GATEWAY_ROUTE))
		return true;
	iph = ip_hdr(skb);
	if (iph->daddr != info->gateway)
		return true;
	return false;

which should be matching

memcmp(&info->gateway, &skb->dst->neighbour->primary_key,
	skb->dst->neighbour->tbl->key_len) == 0 &&
((info->flags & IPT_GATEWAY_ROUTE) == 0 || iph->daddr != info->gateway)

Will resend with that.


	Jan
-- 

RE: [PATCH] xt_gateway match

[Amin Azez]

That looks about right.

Thanks

Sam

-----Original Message-----
From: "Jan Engelhardt" <jengelh@linux01.gwdg.de>
To: "Amin Azez" <azez@ufomechanic.net>
Cc: netfilter-devel@lists.netfilter.org
Sent: 05/06/07 11:16
Subject: RE: [PATCH] xt_gateway match

On Jun 4 2007 11:14, Amin Azez wrote:
>
>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.

Ok I am a bit narrow on this, anyway, I checked again and it looks like, 
yes, there was something wrong. I fixed it to:

	if (memcmp(&info->gateway, &neigh->primary_key, tbl->key_len) != 0)
		return false;
	if (!(info->flags & XT_GATEWAY_ROUTE))
		return true;
	iph = ip_hdr(skb);
	if (iph->daddr != info->gateway)
		return true;
	return false;

which should be matching

memcmp(&info->gateway, &skb->dst->neighbour->primary_key,
	skb->dst->neighbour->tbl->key_len) == 0 &&
((info->flags & IPT_GATEWAY_ROUTE) == 0 || iph->daddr != info->gateway)

Will resend with that.


	Jan
-- 

RE: [PATCH] xt_gateway match

[Jan Engelhardt]

On Jun 5 2007 15:04, Amin Azez wrote:
>
>That looks about right.

Now you can pursue getting it merged ;-)




	Jan
--