I solved the problem described in my last email.
The problem was that we copy pasted the IPv6 address for each vlan
interface, and then changed part of the address for each interface, but
failed to change the prefix length to 64. This meant that each vlan
interface had a different address, but shared the same subnet with other
interfaces. Obviously this resulted in an "unusual" route table -- but it
is unclear to us why the previously described PF problem manifested in the
way it did -- especially given that the ICMPv6 packet used link-local
addresses, and the pass rule did not filter on interface. Seems like it is
possibly a bug.
Joe
On Mon, Apr 30, 2018 at 12:31 PM, Joe Crivello <josephcrivello@gmail.com>
wrote:
> 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