Problem with incoming IPv6 rules that are based on MAC matching

[meyergru]

I have found an apparent problem when I define a rule on the WAN interface that allows IPv6 traffic to a host on the LAN.

The rule in question defines the LAN host by its MAC address via a firewall alias. That is mainly because my ISP assigns dynamic IPv6 prefixes, so that the rules cannot be specified via full IPv6 addresses - or at least they will be outdated when I get another prefix. Thus, specifying a destination host via its MAC seems like a good option.

However, I found that after I reboot my OpnSense or get a new IPv6 prefix, the rule does not fire, but instead the "default deny all" rule blocks incoming IPv6 packets for the LAN host. The command I use to test if the port is open is "nmap -p<port> -Pn -6 <ipv6addr>".

This starts to work only after I trigger an IPv6 neighbor discovery of that host on the OpnSense box, like a ping from OpnSense to the host. It does not work the other way around as the host uses IPv6 privacy extensions and thus usually does not communicate via its EUI-64-based, but over one of its temporary IPv6 addresses.

It can be proven that the neighbor cache is the culprit by looking at "ndp -a", which shows the hosts IPv6 when it works. Once I remove the address with "ndp -d <ipv6addr>", the connection is blocked again.

If I use a firewall rule that is based on the real IPv6 instead of the MAC of the host, it works without having to "introduce" the host in this way first. I would expect the same behavior with a MAC-based rule - I am almost sure that I tried that on 21.x and never had that problem. The MAC trick was discussed by other people as well, who did not have that problem.

I do not get what is wrong here, i.e. why is the packet not matched anyway? Is the MAC-based rule matching depending on the content of the neighbor cache and not followed blindly, like it should? What about IPv4: Is the ARP cache involved there? Is that behavior new in 22.1?

With the advent of more and more IPv6-only ISPs, such problems are becoming quite visible.

[franco]

Since MAC address support is not in pf(4) the MAC alias, similarly to host alias, will resolve MAC addresses to IPs. The facilities it uses are ARP and NDP so yes this is how it worked since it was introduced. And this is the only way it can work in pf(4).


Cheers,
Franco

[meyergru]

Damn. So with changing IPv6 prefixes, the way to go would be to have the possibility of specifying a partly-qualified IPv6 that masks out the dynamic prefix part like what AVM does in their Fritzboxes.

That would need a new alias type, though.

[franco]

Yes, this one maybe? https://docs.opnsense.org/manual/aliases.html#dynamic-ipv6-host


Cheers,
Franco

[meyergru]

My savior! How can I have overlooked that?

This type of alias is robust against NDP.

Big thanks, Franco!


Explanation as to what I was trying to accomplish: Make accessible a port of an IPv6 host behind OpnSense from the WAN side via a DNS entry. My ISP (M-Net) does not offer IPv6 IA-NA, i.e. I do not get an IPv6 on the WAN interface, but only on the LAN interface via IA-PD.

Thus, I need:

1. A working firewall rule that is robust against IPv6 prefix changes (now I have it)
2. Dynamic DNS that can handle a /56 prefix change, but keep the lower 72 bits of the client host (8 bits prefix-ID from "track6" of the LAN interface plus 64 bits interface id derived from the MAC). With this trick, OpnSense can do the dynamic DNS updates for any number of LAN clients and assign different names for them.
That, I have too (by implementing my own DynDNS).