* Strange behavior with ipset not matching on public range
@ 2013-05-27 13:42 Jimmy Thrasibule
2013-05-27 13:49 ` Jozsef Kadlecsik
0 siblings, 1 reply; 7+ messages in thread
From: Jimmy Thrasibule @ 2013-05-27 13:42 UTC (permalink / raw)
To: netfilter
Hi,
I've got a very strange problem with ipset not matching on public IP
addresses.
Let's have a look at my firewall configuration.
# ip addr
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
qlen 1000
link/ether 00:e0:xx:xx:xx:9e brd ff:ff:ff:ff:ff:ff
inet 217.x.x.122/29 brd 217.x.x.127 scope global eth1
# ipset list
Name: fw_iface_pub
Type: hash:net,iface
Header: family inet hashsize 64 maxelem 2
Size in memory: 1552
References: 3
Members:
217.x.x.122,eth1
The entry has been entered in ipset using the following statement:
# ipset add fw_iface_pub 217.x.x.122/32,eth1
So from my point of view, every thing should be OK. Here is the
strangeness:
# iptables -nvL
[...]
Chain FW_OUT (2 references)
pkts bytes target prot opt in out source destination
297 45841 CTRLOUT icmp -- * * 0.0.0.0/0 0.0.0.0/0
77 9731 FW_OUT_common all -- * * 0.0.0.0/0 0.0.0.0/0 match-set fw_iface_all src,dst
0 0 FW_OUT_pub all -- * * 0.0.0.0/0 0.0.0.0/0 match-set fw_iface_pub src,dst
126 22031 FW_OUT_pub all -- * eth1 217.x.x.122 0.0.0.0/0
As you can see, no matches on the `fw_iface_pub` list while the
`fw_iface_all` one matches as well as if I'm directly specify the public
IP address.
And do you want to know what is the stranger part? If I reboot the host,
the rule matches as expected...
I'm running iptables v1.4.14 on Debian 7.0 and I have no idea why this
is happening.
--
Jimmy
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Strange behavior with ipset not matching on public range
2013-05-27 13:42 Strange behavior with ipset not matching on public range Jimmy Thrasibule
@ 2013-05-27 13:49 ` Jozsef Kadlecsik
2013-05-27 14:44 ` Jimmy Thrasibule
0 siblings, 1 reply; 7+ messages in thread
From: Jozsef Kadlecsik @ 2013-05-27 13:49 UTC (permalink / raw)
To: Jimmy Thrasibule; +Cc: netfilter
On Mon, 27 May 2013, Jimmy Thrasibule wrote:
> I've got a very strange problem with ipset not matching on public IP
> addresses.
>
> Let's have a look at my firewall configuration.
>
> # ip addr
> 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> qlen 1000
> link/ether 00:e0:xx:xx:xx:9e brd ff:ff:ff:ff:ff:ff
> inet 217.x.x.122/29 brd 217.x.x.127 scope global eth1
>
> # ipset list
> Name: fw_iface_pub
> Type: hash:net,iface
> Header: family inet hashsize 64 maxelem 2
> Size in memory: 1552
> References: 3
> Members:
> 217.x.x.122,eth1
>
> The entry has been entered in ipset using the following statement:
>
> # ipset add fw_iface_pub 217.x.x.122/32,eth1
>
> So from my point of view, every thing should be OK. Here is the
> strangeness:
>
> # iptables -nvL
> [...]
> Chain FW_OUT (2 references)
> pkts bytes target prot opt in out source destination
> 297 45841 CTRLOUT icmp -- * * 0.0.0.0/0 0.0.0.0/0
> 77 9731 FW_OUT_common all -- * * 0.0.0.0/0 0.0.0.0/0 match-set fw_iface_all src,dst
> 0 0 FW_OUT_pub all -- * * 0.0.0.0/0 0.0.0.0/0 match-set fw_iface_pub src,dst
> 126 22031 FW_OUT_pub all -- * eth1 217.x.x.122 0.0.0.0/0
>
> As you can see, no matches on the `fw_iface_pub` list while the
> `fw_iface_all` one matches as well as if I'm directly specify the public
> IP address.
>
> And do you want to know what is the stranger part? If I reboot the host,
> the rule matches as expected...
>
> I'm running iptables v1.4.14 on Debian 7.0 and I have no idea why this
> is happening.
What is your ipset version? You should post iptables rules in
iptables-save format...
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Strange behavior with ipset not matching on public range
2013-05-27 13:49 ` Jozsef Kadlecsik
@ 2013-05-27 14:44 ` Jimmy Thrasibule
2013-05-27 18:13 ` Jozsef Kadlecsik
0 siblings, 1 reply; 7+ messages in thread
From: Jimmy Thrasibule @ 2013-05-27 14:44 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter
>
> What is your ipset version? You should post iptables rules in
> iptables-save format...
# ipset -V
ipset v6.12.1, protocol version: 6
And here are the rules corresponding to my previous iptables output:
-A FW_OUT -p icmp -j CTRLOUT
-A FW_OUT -m set --match-set fw_iface_all src,dst -j FW_OUT_common # Match
-A FW_OUT -m set --match-set fw_iface_pub src,dst -j FW_OUT_pub # No match
-A FW_OUT -o eth1 -s 217.x.x.122/32 -d any/0 -j FW_OUT_pub # Match
-A FW_OUT -m set --match-set fw_iface_priv src,dst -j FW_OUT_priv # Match
-A FW_OUT -m comment --comment "EOF" -j DROP
>
> Best regards,
> Jozsef
> -
> E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
> PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
> Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
> H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Strange behavior with ipset not matching on public range
2013-05-27 14:44 ` Jimmy Thrasibule
@ 2013-05-27 18:13 ` Jozsef Kadlecsik
2013-05-28 13:30 ` Jimmy Thrasibule
0 siblings, 1 reply; 7+ messages in thread
From: Jozsef Kadlecsik @ 2013-05-27 18:13 UTC (permalink / raw)
To: Jimmy Thrasibule; +Cc: netfilter
On Mon, 27 May 2013, Jimmy Thrasibule wrote:
> > What is your ipset version? You should post iptables rules in
> > iptables-save format...
>
> # ipset -V
> ipset v6.12.1, protocol version: 6
>
> And here are the rules corresponding to my previous iptables output:
>
> -A FW_OUT -p icmp -j CTRLOUT
> -A FW_OUT -m set --match-set fw_iface_all src,dst -j FW_OUT_common # Match
> -A FW_OUT -m set --match-set fw_iface_pub src,dst -j FW_OUT_pub # No match
> -A FW_OUT -o eth1 -s 217.x.x.122/32 -d any/0 -j FW_OUT_pub # Match
> -A FW_OUT -m set --match-set fw_iface_priv src,dst -j FW_OUT_priv # Match
> -A FW_OUT -m comment --comment "EOF" -j DROP
I think you should upgrade: some drivers doesn't zero pad interface names
and than can fool ipset up to 6.12.1. It was fixed in 6.13.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Strange behavior with ipset not matching on public range
2013-05-27 18:13 ` Jozsef Kadlecsik
@ 2013-05-28 13:30 ` Jimmy Thrasibule
2013-05-28 13:33 ` Jimmy Thrasibule
2013-05-28 13:35 ` Jozsef Kadlecsik
0 siblings, 2 replies; 7+ messages in thread
From: Jimmy Thrasibule @ 2013-05-28 13:30 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter
>
> I think you should upgrade: some drivers doesn't zero pad interface names
> and than can fool ipset up to 6.12.1. It was fixed in 6.13.
Looking at the changelog, it looks like 6.13 is fixing an issue which
can be the one I encounter. Do you have a link to this commit or a
commit hash so I can report the bug to the Debian team?
--
Jimmy
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Strange behavior with ipset not matching on public range
2013-05-28 13:30 ` Jimmy Thrasibule
@ 2013-05-28 13:33 ` Jimmy Thrasibule
2013-05-28 13:35 ` Jozsef Kadlecsik
1 sibling, 0 replies; 7+ messages in thread
From: Jimmy Thrasibule @ 2013-05-28 13:33 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter
On Tue, 2013-05-28 at 15:30 +0200, Jimmy Thrasibule wrote:
> >
> > I think you should upgrade: some drivers doesn't zero pad interface names
> > and than can fool ipset up to 6.12.1. It was fixed in 6.13.
>
> Looking at the changelog, it looks like 6.13 is fixing an issue which
> can be the one I encounter. Do you have a link to this commit or a
> commit hash so I can report the bug to the Debian team?
>
> --
> Jimmy
And by the why is their a way to trace this issue? I mean it would be
useful in the bug report to show that something is going the wrong way.
--
Jimmy
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Strange behavior with ipset not matching on public range
2013-05-28 13:30 ` Jimmy Thrasibule
2013-05-28 13:33 ` Jimmy Thrasibule
@ 2013-05-28 13:35 ` Jozsef Kadlecsik
1 sibling, 0 replies; 7+ messages in thread
From: Jozsef Kadlecsik @ 2013-05-28 13:35 UTC (permalink / raw)
To: Jimmy Thrasibule; +Cc: netfilter
On Tue, 28 May 2013, Jimmy Thrasibule wrote:
> > I think you should upgrade: some drivers doesn't zero pad interface names
> > and than can fool ipset up to 6.12.1. It was fixed in 6.13.
>
> Looking at the changelog, it looks like 6.13 is fixing an issue which
> can be the one I encounter. Do you have a link to this commit or a
> commit hash so I can report the bug to the Debian team?
commit ef5b6e127761667f78d99b7510a3876077fe9abe
Author: Florian Westphal <fw@strlen.de>
Date: Sun Jun 17 09:56:46 2012 +0000
netfilter: ipset: fix interface comparision in hash-netiface sets
ifname_compare() assumes that skb->dev is zero-padded,
e.g 'eth1\0\0\0\0\0...'. This isn't always the case. e1000 driver does
strncpy(netdev->name, pci_name(pdev), sizeof(netdev->name) - 1);
in e1000_probe(), so once device is registered dev->name memory contains
'eth1\0:0:3\0\0\0' (or something like that), which makes eth1 compare
fail.
Use plain strcmp() instead.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-05-28 13:35 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-05-27 13:42 Strange behavior with ipset not matching on public range Jimmy Thrasibule
2013-05-27 13:49 ` Jozsef Kadlecsik
2013-05-27 14:44 ` Jimmy Thrasibule
2013-05-27 18:13 ` Jozsef Kadlecsik
2013-05-28 13:30 ` Jimmy Thrasibule
2013-05-28 13:33 ` Jimmy Thrasibule
2013-05-28 13:35 ` Jozsef Kadlecsik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox