Hi pf-hackers,
Some time ago I came across something unintended.
I connected an OpenBSD 4.3-machine to a switch that was
acting like a hub for some traffic (it didn't know
where to send the traffic so it send it to all ports).
I had setup an OpenBSD trunk with just one interface
that was connected to this switch.
The interface did not have an IP-address, just the
trunk-interface had one.
OK, it did have an IPv6-address (it will get that by
default on setting the interface to up), but all
ipv6-traffic was set to drop in pf ( block drop quick
inet6 ).
As you may know, OpenBSD then sets the interface to
promiscious-mode for interfaces which are part of a
trunk (atleast it does this on xl and em).
pf was set to a block-policy of return.
The state-policy was the default: floating
No scrubbing or anything like that was setup.
The driver was em(4) and it was reported and the
interface was reported as the following in dmesg:
Intel PRO/1000 QP (82571EB)
So the machine was getting traffic with the wrong
destination MAC-address on it's interface and the
'fun' part was it would reply with a
'icmp destination unreachable' or similair.
That wasn't the kind of behaviour I was expecting
to see or liked much.
I'm not sure if this is an OpenBSD- or PF-'problem'.
I couldn't think of any other way to deal with it
at the time.
So I set it up without the trunk.
My question is, should PF even have responded to
this traffic at all ? Should OpenBSD have even
have 'passed this along' to pf ?
Also it seems pf isn't able to filter on MAC-address
or some generic filter using the interface-MAC
( like with ($ext_if) ) or did I mis something ?
Now that I think back, maybe I could have done something
with urpf-failed or no-route or much simpeler rule with
drop, but that would just have been a workaround.
Any thoughts on this ?
Have a nice day,
Leen Besselink.
