[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#710883: marked as done (/boot/vmlinuz-3.2.0-4-amd64: iptables PREROUTING match on bridge VLAN interfaces stopped working between 2.6.32 and 3.2)

Your message dated Sat, 24 Apr 2021 05:02:20 -0700 (PDT)
with message-id <608408cc.1c69fb81.314e9.2ced@mx.google.com>
and subject line Closing this bug (BTS maintenance for src:linux bugs)
has caused the Debian Bug report #710883,
regarding /boot/vmlinuz-3.2.0-4-amd64: iptables PREROUTING match on bridge VLAN interfaces stopped working between 2.6.32 and 3.2
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
710883: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710883
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: src:linux
Version: 3.2.41-2+deb7u2
Severity: minor
File: /boot/vmlinuz-3.2.0-4-amd64

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

Dear Maintainer,

Intercepting http traffic entering VLAN tagged on a bridge interface
stopped working after upgrading from Squeeze to Wheezy.

I assume this is an upstream issue, and that it may be fixed upstream
with the introduction of the bridge-nf-pass-vlan-input-dev sysctl.
This does however not seem easily backported to v3.2, as it is based
on other changes to the VLAN/bridge stacking logic.

I have not bothered verifying these assumptions, but have instead
implemented a workaround which is acceptable to me.  Based on this I
do not expect anyone else to use any time investigating this issue.  I
report this bug mostly to document the issue in case someone else
hits it.  Please close or leave open as you find best.

My original setup from squeeze was (simplified and anonymized):

auto br0
iface br0 inet manual
     bridge_ports eth1
     up sysctl -w net.bridge.bridge-nf-filter-vlan-tagged=0

auto br0.7
iface br0.7 inet static
     vlan-raw-device br0
     address 192.168.0.1
     netmask 255.255.255.0

Setting bridge-nf-filter-vlan-tagged=0 used to be the trick to make
iptables match against VLANs stacked on bridge interfaces work. I
was using a rule like this to redirect all http traffic to a local
squid server:

 iptables -t nat -A PREROUTING -i br0.7 -p tcp --dport 80 -j REDIRECT --to-port 3128

But with wheezy this stopped matching.  Enabling a bit of logging
showed that no packets ever appeared with source interface br0.7 in
the PREROUTING chain.  They all had br0 as source interface 
regardless of VLAN tag (used icmp for the log rule, but the results
are similar for tcp and udp):

[862122.574098] IN=br0 OUT= PHYSIN=eth1 MAC=00:15:17:1e:5e:35:00:16:ea:b3:07:88:08:00 SRC=192.168.0.4 DST=91.195.8.200 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=10869 SEQ=1 


Oddly enough, tagged packets entering the nat/INPUT chain from the
same source would appear twice, once with br0 and once with br0.7
as source interface (both lines triggered by the same packet):

[862660.693281] IN=br0 OUT= PHYSIN=eth1 MAC=00:15:17:1e:5e:35:00:16:ea:b3:07:88:08:00 SRC=192.168.0.4 DST=192.168.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=10916 SEQ=1 
[862660.925843] IN=br0.7 OUT= PHYSIN=eth1 MAC=00:15:17:1e:5e:35:00:16:ea:b3:07:88:08:00 SRC=192.168.0.4 DST=192.168.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=10916 SEQ=1 

I did briefly look through some of the changes between v2.6.32
and v3.2, but could spot any obvious cause of this change.

As a workaround I instead modified the rule to use br0 as source
interface, adding an IP source address match to mostly limit it
to packets from clients on VLAN 7.  I also had to add a dummy
address to the br0 interface because the REDIRECT target needs to
rewrite the destination  address.  Resulting workaround is:

auto br0
iface br0 inet static
     bridge_ports eth1
     address 192.168.255.1
     netmask 255.255.255.255

auto br0.7
iface br0.7 inet static
     vlan-raw-device br0
     address 192.168.0.1
     netmask 255.255.255.0


iptables -t nat -A PREROUTING -i br0 -p tcp -s 192.168.0.0/24 --dport 80 -j REDIRECT --to-port 3128


This is uglier than the original setup, bit it solves the task.



Bjørn

- -- Package-specific info:
** Version:
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.41-2+deb7u2

** Command line:
initrd=/initrd.img root=/dev/mapper/vg00-root ro console=tty0 console=ttyS0,9600n8 BOOT_IMAGE=/vmlinuz 

** Not tainted

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlGsVdcACgkQ10rqkowbIslZbACdG8KnbJDTmUnhCGSWvfjNqzQ5
UwwAnApY8abIJW+RbErxLhVdhXNfCFU/
=qHjT
-----END PGP SIGNATURE-----

--- End Message ---
--- Begin Message --- 
Hi

This bug was filed for a very old kernel or the bug is old itself
without resolution.

If you can reproduce it with

- the current version in unstable/testing
- the latest kernel from backports

please reopen the bug, see https://www.debian.org/Bugs/server-control
for details.

Regards,
Salvatore

--- End Message ---
Reply to: