Killing IPv6 communication for a device in LAN

[pawlisko]

Just reading your discussion and what we have in many solutions is an IPv4 architecture that is then repurposed to handle IPv6 or dual-stack.

While IPv4 is well-defined and well-known, IPv6 is not. I don't know what happened, but thinking that NATv6 would not be needed was not based on real-life scenarios. The same thing happened with SLAAC - in theory, this was a good idea, but when you want to control your networks with FW and more, SLAAC does not make sense. Especially with Assisted Mode in RA - my Windows computer now has (at the moment I am writing this) - 4 IPv6 addresses. One from DHCPv6, 1 - LL address, and 2 from SLAAC (including temporary IPv6 address). That alone concerns me as the 2 addresses are dynamic, and pf firewall may not be able to do what I want it to do automatically. The only way to control it is L2 (MAC address).

And yes - you can spoof MAC, you can spoof IP - you can spoof almost everything in the network if you know how to do it. There are protocols to help with this problem, but that also requires knowledge, and time, and will.

So, in the end, what we need is a solution that understands that IPv4 and IPv6 are totally different beasts and probably architecture change is needed. Also, we are in a place where no one cares. We are not simple home users (there is eero/tplink/asus for that), and we are not corporations with IT budgets (there is Cisco/Juniper/etc for that). There are some solutions for us - OPNsense, MikroTik, Ubiquiti, etc but non of those are 100% what we need. There are always some tradeoffs and in the end, what we are using is the solution that sucks the least for us.

The corporate network in my work does not even use IPv6, we are not using NAT - my VDI has a public IP address assigned, of course, everything is controlled by VLANs. switches, routers, ACLs, ADs, etc., but somehow at home, we are using IPv6 - there are services that are using IPv6 only, so we have to adopt it. And again, what we have is a network with Dynamic IPs, with SLAAC devices, with devices that are not 100% compliant with standards (i.e. Android devices at some point), etc. We want to have some control over it, but standards were not written in us in minds, more like the corporate world and unsophisticated home users. What needs to happen is for us to understand and embrace it - go outside the box and stop being ideologues of purity and accept life with greys and build solution around greys.

[meyergru]

But you can actually use IPv6 dynamic host aliases, see here.

I do that for giving access to specific LAN clients based on their MAC via SLAAC. It does not prevent the device to use any other IPv6 with the prefix, for example with IPv6 privacy extensions like described here.

The way with MAC aliases did not work from outside in because OpnSense implements that via intercation with ARP and NDP. This should work to block outgoing IPv6 connections because the LAN client must interact with the firewall before it can communicate outside even if it chooses a fresh IPv6.

From the outside, to guess the correct "privacy" IPv6 is nearly impossible, even if incoming traffic is allowed.

I just tried this and I can block outgoing IPv6 connections from my client. Incoming connections are blocked anyway, modulo the ones I explicitely allow via IPv6 dynamic host aliases.

Of course, you are out of luck if the MAC is being spoofed, but protection at the access layer is not OpnSense's business. Or it is, if you employ FreeRadius with an 802.1x-capable switch, even without certificates. In that case, spoofing the MAC essentially takes you off the network.

[meyergru]

I believe the reason is that, today, this problem (MAC block) is solved with dot1x on a switch. OPNsense is for firewalling and DPI/IPS. Although, you can run RADIUS and try to setup dot1x on an OPNsense, but I was unable to achieve it as there are very little documentation for setting up dot1x on OPNsense.

It is fairly easy, depending on your switch. I got it running with FreeRadius and Unifi Switches. You just use Username and Password the same (namely the MAC in capital letters without separators) and assign a VLAN. You can have a guest or dummy VLAN as the default, which is set as "native" in the 802.1x profile in Unifi controller.

The only thing that was a problem is that you HAVE to assign a VLAN <> 0, such that your usual LAN cannot be untagged for allowed clients. With Unifi, you normally have the untagged as master or native LAN.

The specific format for Username and Password depends on what the switch sends to the Radius server, with Cisco, you can choose between different formats, AFAIK.

[Patrick M. Hausen]

Whoever added "native vlan" to 802.1q deserves to be shot. 

An access port is an access port. A trunk port is a trunk port.

[pawlisko]

So awesome theoretical discussion.

So how about solution for my question? BTW - creating VLANs and additional SSIDs is NOT a valid one.

[meyergru]

You obviously did not read my answer or did not understand it, so once again in more detail:

You can block outgoing IPv6 traffic based on the device MAC, which is exactly what you asked for. However, if the MAC can be spoofed, you are out of luck. And that is the problem essentially, because iOS devices and maybe more do exactly that for privacy reasons.

But if you have 802.1x on the ethernet side and/or can whitelist MACs on WLAN (e.g. Unifi offers that), the device must use a specific MAC (on iOS, you have to configure it to use the "real" MAC) and cannot change it without losing network access completely.

From there, you can block outgoing IPv6 by creating rules on a MAC-based firewall alias. Incoming connections can be blocked too via an IPv6-based prefix alias for the EUI-64 suffix of the device. Of course, IPv6 privacy addresses cannot be blocked for incoming connections (as anybody can use any address), but they are almost impossible to be guessed from outside. Thus, both incoming and outgoing IPv6 would effectively be blocked.

You should also block IPv6 traffic from the device to and from the firewall itself (like DHCPv6), because once a device even thinks it has a valid IPv6, it will start talking regardless if it is being blocked, resulting in delays beofre it switches to IPv4. You cannot block broadcasts like RAs, however.