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-----
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20130603083746.7455.9879.report...@canardo.mork.no
