Skip to contentSkip to conversation

Policy match with a bridge

DISCUSSION Tom Eastep 3 participants 9 messages Aug 15, 2004 – Oct 16, 2004

Subsystems (2)
netfilter Ethernet bridge
lore
Share & tools
lore

Tom Eastep

author
#0 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm seeing odd behavior of policy match when used with a bridge.

wookie:/backup # iptables -L -n -v
Chain INPUT (policy ACCEPT 12M packets, 1412M bytes)
~ pkts bytes target prot opt in out source
destination

Chain FORWARD (policy ACCEPT 57181 packets, 12M bytes)
~ pkts bytes target prot opt in out source
destination

Chain OUTPUT (policy ACCEPT 16M packets, 21G bytes)
~ pkts bytes target prot opt in out source
destination

wookie:/backup # iptables -A OUTPUT -m policy --pol ipsec --dir out -j LOG

wookie:/backup # ping tipper
PING tipper.shorewall.net (192.168.1.8) 56(84) bytes of data. 64 bytes from tipper.shorewall.net (192.168.1.8): icmp_seq=1 ttl=64 time=4.45 ms
64 bytes from tipper.shorewall.net (192.168.1.8): icmp_seq=2 ttl=64 time=3.81 ms
64 bytes from tipper.shorewall.net (192.168.1.8): icmp_seq=3 ttl=64 time=3.48 ms
64 bytes from tipper.shorewall.net (192.168.1.8): icmp_seq=4 ttl=64 time=3.56 ms
64 bytes from tipper.shorewall.net (192.168.1.8): icmp_seq=5 ttl=64 time=4.16 ms
64 bytes from tipper.shorewall.net (192.168.1.8): icmp_seq=6 ttl=64 time=3.71 ms

- --- tipper.shorewall.net ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5010ms rtt min/avg/max/mdev = 3.483/3.863/4.452/0.340 ms

wookie:/backup # setkey -D
192.168.1.3 192.168.1

~        esp mode=transport spi=170223379(0x0a256713) reqid=0(0x00000000)
~        E: 3des-cbc  7ebd7b0f a852467c ada833a2 3b5744fc 4ab0d47d b347e694
~        A: hmac-sha1  64872be1 24233626 6429e838 8dcb7a15 159bfb12
~        seq=0x00000000 replay=4 flags=0x00000000 state=mature
~        created: Aug 14 11:04:49 2004   current: Aug 14 17:19:23 2004
~        diff: 22474(s)  hard: 43200(s)  soft: 34560(s)
~        last: Aug 14 11:04:49 2004      hard: 0(s)      soft: 0(s)
~        current: 2416880(bytes) hard: 0(bytes)  soft: 0(bytes)
~        allocated: 8941 hard: 0 soft: 0
~        sadb_seq=1 pid=30723 refcnt=0
192.168.1.8 192.168.1.3
~        esp mode=transport spi=233099158(0x0de4cf96) reqid=0(0x00000000)
~        E: 3des-cbc  ce5a582a f621e4e5 84597866 ef941902 f4140957 01ada36d
~        A: hmac-sha1  3a9394f7 439b0f4e 4fed679a 74710c67 c658146e
~        seq=0x00000000 replay=4 flags=0x00000000 state=mature
~        created: Aug 14 11:04:49 2004   current: Aug 14 17:19:23 2004
~        diff: 22474(s)  hard: 43200(s)  soft: 34560(s)
~        last: Aug 14 11:04:49 2004      hard: 0(s)      soft: 0(s)
~        current: 1208740(bytes) hard: 0(bytes)  soft: 0(bytes)
~        allocated: 12222        hard: 0 soft: 0
~        sadb_seq=0 pid=30723 refcnt=0

wookie: /backup # iptables -L OUTPUT -n -v Chain OUTPUT (policy ACCEPT 16M packets, 21G bytes)
~ pkts bytes target prot opt in out source
destination
~ 0 0 LOG all -- * * 0.0.0.0/0
0.0.0.0/0 policy match dir out pol ipsec
LOG flags 0 level 4

wookie:/backup # brctl show

bridge name     bridge id               STP enabled     interfaces
br0             8000.0040d0073a1b       no              eth1

~ eth0
~ eth2

wookie:/backup # ip addr ls br0
6: br0: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc noqueue

~    link/ether 00:40:d0:07:3a:1b brd ff:ff:ff:ff:ff:ff
~    inet 192.168.1.3/24 brd 192.168.1.255 scope global br0
~    inet6 fe80::240:d0ff:fe07:3a1b/64 scope link

~ valid_lft forever preferred_lft forever

wookie:/backup # uname -a
Linux wookie 2.6.5-7.104-default #1 Wed Jul 28 16:42:13 UTC 2004 i586 i586 i386 GNU/Linux
wookie:/backup #

- -Tom
- --
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ [email protected]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBHq8IO/MAbZfjDLIRAvKSAJ94NFMjdEYBOFzZeh0Cg2LpCpLYZgCdHl/7 NTIe5dxB4jbSMfvSEu0Am7s=
=q4Ie
-----END PGP SIGNATURE-----

#1 lore raw
Quoted 8 lines · Tom Eastep

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm seeing odd behavior of policy match when used with a bridge.

wookie:/backup # uname -a
Linux wookie 2.6.5-7.104-default #1 Wed Jul 28 16:42:13 UTC 2004 i586 i586 i386 GNU/Linux

Have you applied the ipsec+netfilter patches ? Without them, packets are only seen encrypted in the OUTPUT chain.

Regards
Patrick

author
#2 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick McHardy wrote:

| Tom Eastep wrote:
|
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> I'm seeing odd behavior of policy match when used with a bridge.
|>
|> wookie:/backup # uname -a
|> Linux wookie 2.6.5-7.104-default #1 Wed Jul 28 16:42:13 UTC 2004 i586
|> i586 i386 GNU/Linux
|
|
| Have you applied the ipsec+netfilter patches ? Without them, packets are
| only seen encrypted in the OUTPUT chain.
|

Yes -- the ipsec+netfilter patches are applied. Here is the same test with the bridge removed and the local ip address transfered to one of the network cards:

wookie:~ # iptables -L -n -v
Chain INPUT (policy ACCEPT 137 packets, 18014 bytes)
~ pkts bytes target prot opt in out source
destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
~ pkts bytes target prot opt in out source
destination

Chain OUTPUT (policy ACCEPT 100 packets, 14110 bytes)
~ pkts bytes target prot opt in out source
destination
wookie:~ # iptables -A OUTPUT -m policy --pol ipsec --dir out -j ACCEPT wookie:~ # ping tipper
PING tipper.shorewall.net (192.168.1.8) 56(84) bytes of data. 64 bytes from tipper.shorewall.net (192.168.1.8): icmp_seq=1 ttl=64 time=4.19 ms
64 bytes from tipper.shorewall.net (192.168.1.8): icmp_seq=2 ttl=64 time=3.45 ms
64 bytes from tipper.shorewall.net (192.168.1.8): icmp_seq=3 ttl=64 time=3.49 ms
64 bytes from tipper.shorewall.net (192.168.1.8): icmp_seq=4 ttl=64 time=3.32 ms

- --- tipper.shorewall.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms rtt min/avg/max/mdev = 3.327/3.617/4.195/0.339 ms wookie:~ # iptables -L -n -v
Chain INPUT (policy ACCEPT 482 packets, 50100 bytes)
~ pkts bytes target prot opt in out source
destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
~ pkts bytes target prot opt in out source
destination

Chain OUTPUT (policy ACCEPT 269 packets, 36010 bytes)
~ pkts bytes target prot opt in out source
destination
~ 28 3376 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 policy match dir out pol ipsec

wookie:~ #

- -Tom
- --
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ [email protected]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBH3uHO/MAbZfjDLIRAvIhAJ4x6l+LJ7pSp/vnrqHlSeOidn0oAACgrZv6 Xrm70xeiqgHYKOle8YSce14=
=ZChs
-----END PGP SIGNATURE-----

#3 lore raw
Quoted 6 lines · Tom Eastep
| Have you applied the ipsec+netfilter patches ? Without them, packets are
| only seen encrypted in the OUTPUT chain.
|

Yes -- the ipsec+netfilter patches are applied. Here is the same test with the bridge removed and the local ip address transfered to one of the network cards:

The problem is ipv4_sabotage_out in the briding code. It prevents the packet from hitting the LOCAL_OUT hook while it is still unencrypted. When it hits the bridging code and its LOCAL_OUT hook it's too late. Not sure how to handle it yet.

Regards
Patrick

author
#4 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick McHardy wrote:

| Tom Eastep wrote:
|
|> | Have you applied the ipsec+netfilter patches ? Without them, packets
|> are
|> | only seen encrypted in the OUTPUT chain.
|> |
|> Yes -- the ipsec+netfilter patches are applied. Here is the same test
|> with the bridge removed and the local ip address transfered to one of
|> the network cards:
|
|
| The problem is ipv4_sabotage_out in the briding code. It prevents the
| packet from hitting the LOCAL_OUT hook while it is still unencrypted.
| When it hits the bridging code and its LOCAL_OUT hook it's too late.
| Not sure how to handle it yet.
|

Thanks for the update.

- -Tom
- --
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ [email protected]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBIBFOO/MAbZfjDLIRAvS4AJ9eGQhcxVi09h8gmLZ/CpauSYlw1wCePgBQ trHWmX/wZV/DyIjSz05IGyQ=
=mL/B
-----END PGP SIGNATURE-----

#5 lore raw
In reply to Patrick McHardy
Quoted 4 lines · Patrick McHardy

The problem is ipv4_sabotage_out in the briding code. It prevents the packet from hitting the LOCAL_OUT hook while it is still unencrypted. When it hits the bridging code and its LOCAL_OUT hook it's too late. Not sure how to handle it yet.

I'll have a look at that after I'm finished with the IPv6 bridge firewalling stuff.

cheers,
Bart

author
#6 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 9 lines · Bart De Schuymer
Quoted 4 lines · Patrick McHardy

The problem is ipv4_sabotage_out in the briding code. It prevents the packet from hitting the LOCAL_OUT hook while it is still unencrypted. When it hits the bridging code and its LOCAL_OUT hook it's too late. Not sure how to handle it yet.

I'll have a look at that after I'm finished with the IPv6 bridge

firewalling

Quoted 2 lines

stuff.

Any progress on this?

Thanks,
- -Tom
- --
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ [email protected]
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBbcbvO/MAbZfjDLIRAmBsAJsFlFdf6+c5tzT8Z5OGG/nnxoL//wCghS8L hX2rkQdtF2v7YIwRyfRDLIY=
=6sB9
-----END PGP SIGNATURE-----

#7 lore raw
Quoted 7 lines · Tom Eastep
Quoted 6 lines · Bart De Schuymer
Quoted 4 lines · Patrick McHardy

The problem is ipv4_sabotage_out in the briding code. It prevents the packet from hitting the LOCAL_OUT hook while it is still unencrypted. When it hits the bridging code and its LOCAL_OUT hook it's too late. Not sure how to handle it yet.

Quoted 7 lines
Quoted 1 line

I'll have a look at that after I'm finished with the IPv6 bridge

firewalling

Quoted 1 line

stuff.

Any progress on this?

It's in the back of my mind, but I haven't had time yet to look into the ipsec code. I'll try next weekend. It's probably non-trivial, as Patrick didn't see a direct solution.

cheers,
Bart

#8 lore raw
In reply to Tom Eastep
Quoted 7 lines · Tom Eastep
Quoted 6 lines · Bart De Schuymer
Quoted 4 lines · Patrick McHardy

The problem is ipv4_sabotage_out in the briding code. It prevents the packet from hitting the LOCAL_OUT hook while it is still unencrypted. When it hits the bridging code and its LOCAL_OUT hook it's too late. Not sure how to handle it yet.

Quoted 7 lines
Quoted 1 line

I'll have a look at that after I'm finished with the IPv6 bridge

firewalling

Quoted 1 line

stuff.

Any progress on this?

You should be able to do what you want in the iptables mangle OUTPUT chain instead of the one in the filter table.
Patrick, a hack solution would be to temporarily change out->hard_start_xmit to something else than br_dev_xmit, that way you fool ipv4_sabotage_out.

cheers,
Bart