Your message dated Sat, 24 Apr 2021 05:02:20 -0700 (PDT) with message-id <[email protected]> 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 [email protected] immediately.) -- 710883: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710883 Debian Bug Tracking System Contact [email protected] 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 ([email protected]) (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 ---
