Monday, April 30, 2018

ICMPv6 Neighbor Advertisement PF Weirdness

Hello --

While configuring a new firewall, I noticed that pflog0 was showing that
some ICMPv6 neighbor advertisement packets were being blocked in on vlan51,
which is a sub-interface of vmx1 (a vmxnet3 interface using VGT). I added a
PF rule allowing this traffic to pass. However, even after adding the rule
and flushing all state, the traffic was still being reported as blocked in
by pflog0. Thinking that there might be something else wrong with the rule
set, I made the pass rule "quick" and inserted it as the first pass rule in
the set. This still didn't work.

See below for (1) the first two rules of the rule set (they are the only
ones that matter in this example), (2) a tcpdump that was run after the
rule set was applied and states were flushed, showing the blocked traffic,
and (3) the interface configurations in question.

# pfctl -sr
FILTER RULES:
block drop log all label "Block all"
pass in quick on any inet6 proto ipv6-icmp all icmp6-type neighbradv

# tcpdump -netvvi pflog0 "icmp6 && ip6[40] == 136"
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
rule 1/(match) [uid 0, pid 91607] block in on vlan51:
fe80::1905:23c0:fe7a:dcfe > ff02::1: [|icmp6] (len 32, hlim 255)
^C
7 packets received by filter
0 packets dropped by kernel

# ifconfig vmx1
vmx1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0c:29:50:66:d1
index 2 priority 0 llprio 3
media: Ethernet autoselect (10GbaseT)
status: active
inet6 fe80::20c:29ff:fe50:66d1%vmx1 prefixlen 64 scopeid 0x2

# ifconfig vlan51
vlan51: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0c:29:50:66:d1
description: <SNIP>
index 7 priority 0 llprio 3
encap: vnetid 51 parent vmx1
groups: vlan inetusr resolverusr
media: Ethernet autoselect (10GbaseT)
status: active
inet6 fe80::20c:29ff:fe50:66d1%vlan51 prefixlen 64 scopeid 0x7
inet 10.84.51.1 netmask 0xffffff00 broadcast 10.84.51.255
inet6 <SNIP>::1 prefixlen 56

The firewall is a VMware ESXi 6.5 virtual machine running
SecurityRouter.org 6.2-lyra -- which is a distribution based on OpenBSD 6.2.

Thinking that this might be a problem with the vmx(4) driver, we changed
the network interface to emulated E1000e (em(4)), no change. Also tried
adding "allow-opts" to the pass rule, no change.

I understand this list isn't meant to support SecurityRouter.org's
distribution of OpenBSD... but does anyone see something obviously wrong
with my rule set or my expectations of how it should behave? Are there
known problems with using VGT on VMware ESXi with vmx(4) and em(4) drivers?
I reviewed the 6.2 errata and didn't see anything pertinent.

Joe

No comments:

Post a Comment