Re: bridge+netfilter broken for IP fragments in 2.6.16?

Re: bridge+netfilter broken for IP fragments in 2.6.16?

[Thomas Zeitlhofer]

On Sun, Apr 02, 2006 at 09:19:30PM +0200, Patrick McHardy wrote:
> Thomas Zeitlhofer wrote:
> > I have set up a bridge with two ports:
> > 
> > # brctl show br0
> > bridge name     bridge id               STP enabled     interfaces
> > br0             8000.000021f23d58       no              eth1
> >                                                         tap1
> > 
> > Using 2.6.16/.1 non fragmented IP packets are passing the bridge without
> > problems, but fragmented IP packets do not show up on the outgoing
> > interface. E.g., for fragmented traffic coming in from tap1 and going
> > out via eth1 tcpdump shows:
> > 
> >   1) on tap1: fragmented packets
> >   2) on br0: the defragmented packet (connection tracking)
> >   3) on eth1: no packet!?
> > 
> > This breaks IPsec connections for example.
> > 
> > 
> > Doing the same on 2.6.15.x shows:
> > 
> >   1) on tap1: fragmented packets
> >   2) on br0: the defragmented packet (connection tracking)
> >   3) on eth1: fragmented packets
> 
> Are you sure this is correct? I think in 2.6.15 you should see
> the fragments on br0 already.

Just verified it, at least in 2.6.15.6 tcpdump shows the defragmented
packet on br0.

> Anyway, since 2.6.16 ip_conntrack doesn't do refragmentation anymore
> but relies on fragmentation in the IP layer. Purely bridged packets
> don't go through the IP layer, so the bridge netfilter code needs to
> take care of fragmentation itself. Please try if this patch helps.

Your patch solves the problem - tcpdump now shows the refragmented
packets on eth1. Thanks for the quick solution.

Just a note, your patch does not work when bridge is compiled as a
module. In this case modprobe failes with "bridge: Unknown symbol
ip_fragment". Using CONFIG_BRIDGE=y works.

> > and IPsec connections are ok.
> 
> This is probably a different issue. 

I don't think so, with your patch IPsec connection can be established
again. The problem was that racoon generates UDP packets of length 2600
during isakmp phase 1 which did not pass the bridge. 

> Please describe your setup (IPsec, NAT and filtering).

The setup here is UML behind tap1 where br0 is used to bridge the
physical interface (eth1) to the UML's eth0 (=> tap1). The IPsec
connection is going from the UML to the outside world over the bridge.
NAT is not used and at the moment filtering is just used for
accounting. So nothing special, only two rules in the FORWARD chain
that accept all traffic in both directions.

--
Thomas

Re: bridge+netfilter broken for IP fragments in 2.6.16?

[Patrick McHardy]

Thomas Zeitlhofer wrote:
> On Sun, Apr 02, 2006 at 09:19:30PM +0200, Patrick McHardy wrote:
> 
>>>Doing the same on 2.6.15.x shows:
>>>
>>>  1) on tap1: fragmented packets
>>>  2) on br0: the defragmented packet (connection tracking)
>>>  3) on eth1: fragmented packets
>>
>>Are you sure this is correct? I think in 2.6.15 you should see
>>the fragments on br0 already.
> 
> 
> Just verified it, at least in 2.6.15.6 tcpdump shows the defragmented
> packet on br0.

I'm probably missing something, but that still seems stange.
Are you also seeing the defragmented packet on br0 with my
patch?

>>Anyway, since 2.6.16 ip_conntrack doesn't do refragmentation anymore
>>but relies on fragmentation in the IP layer. Purely bridged packets
>>don't go through the IP layer, so the bridge netfilter code needs to
>>take care of fragmentation itself. Please try if this patch helps.
> 
> 
> Your patch solves the problem - tcpdump now shows the refragmented
> packets on eth1. Thanks for the quick solution.
> 
> Just a note, your patch does not work when bridge is compiled as a
> module. In this case modprobe failes with "bridge: Unknown symbol
> ip_fragment". Using CONFIG_BRIDGE=y works.

Thanks, I missed that the Makefile adds br_netfilter.o to
bridge-$(CONFIG_BRIDGE_NETFILTER), not obj-$(...).

Re: bridge+netfilter broken for IP fragments in 2.6.16?

[Thomas Zeitlhofer]

On Mon, Apr 03, 2006 at 01:11:46AM +0200, Patrick McHardy wrote:
> Thomas Zeitlhofer wrote:
> > On Sun, Apr 02, 2006 at 09:19:30PM +0200, Patrick McHardy wrote:
> > 
> >>>Doing the same on 2.6.15.x shows:
> >>>
> >>>  1) on tap1: fragmented packets
> >>>  2) on br0: the defragmented packet (connection tracking)
> >>>  3) on eth1: fragmented packets
> >>
> >>Are you sure this is correct? I think in 2.6.15 you should see
> >>the fragments on br0 already.
> > 
> > 
> > Just verified it, at least in 2.6.15.6 tcpdump shows the defragmented
> > packet on br0.
> 
> I'm probably missing something, but that still seems stange.
> Are you also seeing the defragmented packet on br0 with my
> patch?

Yes, here is the tcpdump output on all interfaces: 

1) on tap1
23:22:51.830046 IP (tos 0x0, ttl  64, id 21174, offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.10.1.500 > 192.168.20.1.500: isakmp 1.0 msgid : phase 1 I ident[E]: [encrypted id] (len mismatch: isakmp 2572/ip 1472)
23:22:51.830084 IP (tos 0x0, ttl  64, id 21174, offset 1480, flags [none], proto: UDP (17), length: 1120) 192.168.10.1 > 192.168.20.1: udp 

2) on br0
23:22:51.830084 IP (tos 0x0, ttl  64, id 21174, offset 0, flags [none], proto: UDP (17), length: 2600) 192.168.10.1.500 > 192.168.20.1.500: isakmp 1.0 msgid : phase 1 I ident[E]: [encrypted id]

3) on eth1 
23:22:51.830120 IP (tos 0x0, ttl  64, id 21174, offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.10.1.500 > 192.168.20.1.500: isakmp 1.0 msgid : phase 1 I ident[E]: [encrypted id] (len mismatch: isakmp 2572/ip 1472)
23:22:51.830133 IP (tos 0x0, ttl  64, id 21174, offset 1480, flags [none], proto: UDP (17), length: 1120) 192.168.10.1 > 192.168.20.1: udp

--
Thomas