Matt Hamilton <matth <at> netsight.co.uk> writes: > > Hi All, > I just been upgrading a router from OpenBSD 5.1 to 5.4 and hit a > big problem
Doh! I meant 5.5, not 5.4. Digging about it looks like the following change by Henning may shed some light: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c ?rev=1.837&content-type=text/x-cvsweb-markup&f=h Specifically the comment: "in all output pathes, very late, if we figure out the outbound interface doesn't have hw cksum offloading, do the cksum in software. this especially makes the bridge path behave like a regular output path" Now, if I have a bridge, with two members, one that can do offloading (bnx) and one that can't (tun), what happens? And anyway which is the output interface anyway? e.g. if I had the following setup: # cat /etc/hostname.vlan101 vlan 101 vlandev trunk0 description "Office network" -inet6 up # cat /etc/hostname.carp101 carpdev vlan101 vhid 101 pass secret advskew 100 inet 192.168.87.1 255.255.255.0 description "Office Network" -inet6 # cat /etc/hostname.tun0 link0 up description "OpenVPN tunnel interface" # cat /etc/hostname.bridge0 add vlan101 add tun0 up description "OpenVPN bridge for tun and vlan101" When a packet is destined to 192.168.87.10 which is on the end of the OpenVPN tunnel, ie according to bridge0 it is on tun0... what is the outbound interface according to PF and the code that makes the decision Henning talks about above? -Matt
