Quick question - as I am new to the OPNsense world.
Killing (temporarily) IPv6 communication for a device inside LAN. In MikroTik, I would create rules in FW to drop in/out IPv6 transmission based on the device MAC address (due to the device being SLAAC only), and I can't turn off IPv6 support in the device. Basically if device sniffs IPv6 it will go for IPv6 address and communication.
I tried to replicate it here with partial success. Some transmission is going through thou on intermittent bases.
What is the proper way in OPNsense to kill IPv6 communication for the host?
OPNsense is based on FreeBSD which doesn't firewall on MAC address. You can assign a separate VLAN on your managed switch to the device and disable IPv6 on that.
It sounds like it was easier to code on L3 rather than on L2 and we are stuck with solution witch is way sub-optimal and to workaround that we need to create so much more than it needs.
Your solution is manageable if device is connected through ethernet, but what - change of WLAN or creating additional SSIDs for WiFi for each device does not make sense. What if I have 5 devices like that and I want for 4 to use IPv6 than what? 5 VLANs? 5 WiFi networks? What about ease of use? Not to mention support or troubleshooting.
how about getting those devices a static ip(4 and/or 6) and block it on ip, or when several, making an alias with those ips and blocking it. I am using that for my kids devices to block the internet for them to support bedtime :-)
OPNsense does have MAC addresses as aliases in the firewall section. Can't it set up rules with these as source or destination?
Those MAC addresses as aliases don't seem t work. About a year ago I tried that approach in the captive portal and got an answer back like what @bartjsmit is saying that opnsense/freebsd does not firewall mac addresses.
That is when I set up all devices on the network with static ip, not a known device, no connection, and being able to control the connection of every device.
Would be an awesome feature if the MAC addresses would be included also
Quote from: RamSense on December 28, 2022, 06:07:08 PM
how about getting those devices a static ip(4 and/or 6) and block it on ip, or when several, making an alias with those ips and blocking it. I am using that for my kids devices to block the internet for them to support bedtime :-)
IPv4 - I setup it up as static, so it is easy to configure - No issue here
IPv6 - is using SLAAC - hence my original post about sniffing out IPv6 address. So device can use DHCPv6 but because I have some which can't I have to use RA in Assisted mode (Flags M+O+A), and many devices, including the device in question, prefer SLAAC over DHCPv6.
For kids devices I use built in Kids Mode (iOS and Amazon - did that right).
Quote from: RamSense on December 28, 2022, 07:31:32 PM
Those MAC addresses as aliases don't seem t work. About a year ago I tried that approach in the captive portal and got an answer back like what @bartjsmit is saying that opnsense/freebsd does not firewall mac addresses.
That is when I set up all devices on the network with static ip, not a known device, no connection, and being able to control the connection of every device.
Would be an awesome feature if the MAC addresses would be included also
Oops :)
I was planning to use exactly these to permit only my laptop and iPad from the family VLAN into the management VLAN. Let's see - I'll report back.
Out of curiousity I set up a MAC alias for my Android phone and turned on IPv6 support on my Wifi vlan and RA service with Assisted mode.
I could see my phone got a SLAAC address and the MAC alias from OPNSense's Diagnostics->Aliases also resolved to the same address.
Then I setup a block rule for that MAC alias and it seems to be working as expected.
So it looks like OPNSense can firewall by MAC address just fine, what do I miss here?
Quote from: zan on December 29, 2022, 08:30:43 AM
Out of curiousity I set up a MAC alias for my Android phone and turned on IPv6 support on my Wifi vlan and RA service with Assisted mode.
I could see my phone got a SLAAC address and the MAC alias from OPNSense's Diagnostics->Aliases also resolved to the same address.
Then I setup a block rule for that MAC alias and it seems to be working as expected.
So it looks like OPNSense can firewall by MAC address just fine, what do I miss here?
SLAAC IPv6 addresses tend to change. There are devices like i.e. my printer which has one IPv6 address based on MAC address, but iOS devices are taking 2 IPv6 addresses and then start to circulate then taking new address etc, same situation is with Windows. So other people said FBSD is working on L3 (IP level) not on L2 (MAC level). MAC addresses are resolved to IP addresses every 5 minutes. So if your IPv6 changed 1 second after OPNsense refreshed it to block, your device has 4 minutes and 59 seconds when it is not technically blocked as new IPv6 address is not blocked.
More precisely the pf firewall in FreeBSD according to the documentation only works on layer 3 and layer 4 information. There are three different firewalls in FreeBSD and e.g. ipfw works perfectly well on MAC addresses (layer 2).
Why pfSense and consequently OPNsense picked pf over ipfw I don't know. But that's the state of affairs it seems. During the years I built FreeBSD based routers and VPN gateways from scratch I always used ipfw.
Most, if not all commercial enterprise grade firewalls don't go below layer 3 either. MAC addresses are too easily spoofed and enforcement of layer 2 security is best done on switches through VLAN separation.
I know you can spoof IP addresses as well, but that's not much good to an attacker if they can't break out of the corresponding VLAN.
Bart...
Quote from: pmhausen on December 29, 2022, 07:50:35 PM
More precisely the pf firewall in FreeBSD according to the documentation only works on layer 3 and layer 4 information. There are three different firewalls in FreeBSD and e.g. ipfw works perfectly well on MAC addresses (layer 2).
Why pfSense and consequently OPNsense picked pf over ipfw I don't know. But that's the state of affairs it seems. During the years I built FreeBSD based routers and VPN gateways from scratch I always used ipfw.
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.
Another alternative is MAC based VLAN assignment via VMPS with FreeRADIUS. I used to run that for a while. Every device not explicitly configured ends up in the guest VLAN. Or a "dead" one, depending on your policy.
Also needs support on the switch side, of course.
Nice... :) Cisco only though...
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.
But you can actually use IPv6 dynamic host aliases, see here (https://forum.opnsense.org/index.php?topic=27483.0).
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 (https://forum.opnsense.org/index.php?action=post;quote=133400;topic=27483.0;last_msg=133411). 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.
Quote from: lilsense on December 30, 2022, 01:05:58 PM
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.
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.
So awesome theoretical discussion.
So how about solution for my question? BTW - creating VLANs and additional SSIDs is NOT a valid one.
You obviously did not read my answer (https://forum.opnsense.org/index.php?action=post;quote=152904;topic=31554.0;last_msg=153202) 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.