I'd like to keep "pure" VLAN interfaces with the parent interface (e.g. igc2) disabled and unassigned, as it's my understanding that that is best practice for tags-only interfaces where there should not be untagged traffic. It also prevents potential routing issues if a parent gets an IP for some reason.
I'd also like to change the MAC on all internal parent interfaces as a security measure against applications leaking firewall OUI / manufacturer info to the outside.
Unless I'm mistaken this is currently not possible, because parent interfaces must be assigned in Interfaces->Assignments and Enabled in order to set a MAC address. The only way around it is to set a per-VLAN (child interface) MAC and then must use promiscuous mode.
I tried setting the MAC and then disabling the parent, but the MAC change did not persist for the VLAN interfaces in that case.
Does this support already exist? Could it become a feature, if I were to raise a GitHub issue tracker?
You cloud keep the parent interface enabled but not configured. That way you can spoof the MAC address on it.
I'll have to see if I can find them but some older posts recommend to keep those disabled unassigned. I think franco had done some work to make that possible.
Looks like it's been an option since 22.7.4
https://forum.opnsense.org/index.php?topic=39129.0
https://forum.opnsense.org/index.php?topic=43781.0
I agree with some of the comments in those threads and like that keeping them unassigned also keeps the L2 topology abstracted and the interface list clean.
The documentation suggests to do the same, but it makes an exception in case of manual link speed assignment:
Quote from: https://docs.opnsense.org/manual/how-tos/vlan_and_lagg.htmlGo to Interfaces ‣ Assignments and assign the new VLAN interfaces. The parent interface should stay unassigned. In rare cases, the parent interface can be assigned without a network configuration, to allow manual link speed overrides.
I suppose my use case may arguably fall under the "
in rare cases" category, but I'd like to suggest that certain interface settings could maybe be decoupled from the Interfaces UI and exposed as global settings. Link speed override and hw_mac override could be candidates.
I'll submit a feature request if the dev team thinks this is something that might reasonably move forward.
---
In case leaving the parent interfaces assigned/enabled and unconfigured is the long term solution then I would like to ask if that is functionally the same as leaving them unassigned. What potential behavior differences could one expect between those two methods?
Thank you!
Quote from: OPNenthu on August 12, 2025, 12:38:06 AM[...]
In case leaving the parent interfaces assigned/enabled and unconfigured is the long term solution then I would like to ask if that is functionally the same as leaving them unassigned. [...]
Apparently, as that's what I did.
I've seen some strangeness in the past so am a bit skeptical on that being ideal in all environments. I do recall receiving untagged frames on my VLAN trunk at one point (visible in the pf live view), and also an issue with IPv6 RA leakage causing clients to get GUAs from all VLANs.
I've not seen any such issues since moving to a pure VLAN trunk port, tags only.
Maybe some of this is more readily apparent on specific switches and port settings than others (in misconfigurations certainly, but maybe also normally in some brands/models).
FWIW, this is what I was able to get out of ChatGPT after prompting it on issues for OPNsense and FreeBSD networking in general. In summary:
Quote🔍 TL;DR:
When a VLAN parent interface is assigned (even without an IP), it can still receive and process broadcast/multicast traffic, including:
DHCP requests/offers
Router Advertisements (RAs)
IPv6 Neighbor Discovery (ND)
Other L2 multicast or broadcast traffic
This opens the door to "leaks" — where traffic not meant for the parent interface is received, logged, or acted upon by services running on the firewall.
I'm not a networking expert so can't fact check this, but it does align with advice I've seen on the forum and some personal observations.
Ergo why I feel it's best to move link speed and hw_mac override to their own section in the UI where they can exist independently of the parent interface being assigned/enabled or not. Then admins can have a choice about how to keep their parent interfaces.
Quote from: OPNenthu on August 11, 2025, 08:28:53 AM[...]
I'd also like to change the MAC on all internal parent interfaces as a security measure against applications leaking firewall OUI / manufacturer info to the outside.
[...]
Why do you think changing the MAC address improves security? Of course, the original MAC address reveals the manufacturer of the network card or motherboard, but only to devices on the same Layer 2 network segment. MAC addresses are not transmitted across routers.
For a long time, I used a custom, locally managed MAC address for the WAN interface to avoid problems with my ISP if my hardware changed. This configuration worked perfectly for many years and with several different ISPs, until a few weeks ago.
What happened? My ISP, Deutsche Glasfaser, was conducting maintenance work in our area. During this exact time, the internet connection went down overnight. Absolutely no communication was possible; the remote end simply didn't respond to any of the sent Ethernet frames. It was a tedious process to resolve the issue, especially because the non-technical support provided conflicting and incorrect information :-(.
After a thorough technical investigation, I discovered that the ISP was using similar MAC addresses for its own infrastructure after completing maintenance. Apparently, the ISP allocated the MAC address range, which also included my custom address, and applied an inbound filter for the CPE to prevent MAC address collisions. After updating the MAC address for the WAN interface, everything worked again.
Quote from: schnipp on August 13, 2025, 06:00:50 PMWhy do you think changing the MAC address improves security? Of course, the original MAC address reveals the manufacturer of the network card or motherboard, but only to devices on the same Layer 2 network segment. MAC addresses are not transmitted across routers.
It's maybe a niche use case, but I am thinking that internal applications and loggers don't really have a need to know who makes the router. Here I am thinking about benign and helpful ones as well, such as the UniFi controller and Wireshark.
In recent years my ISP also moved to virtualized infrastructure. That's good to know that this kind of filtering could be done. Happily, I've already changed my WAN MAC successfully.
Quote from: OPNenthu on August 13, 2025, 08:52:24 PMIt's maybe a niche use case, but I am thinking that internal applications and loggers don't really have a need to know who makes the router.
Sounds really niche to me. I want my NMS to know the brands of my components so I can identify devices by that information. If you don't trust your NMS you might have a problem.
Quote from: OPNenthu on August 12, 2025, 03:00:59 AM[...]
I've not seen any such issues since moving to a pure VLAN trunk port, tags only. [...]
Yep, same here. I simply have the main interface "assigned" - didn't bother to unassign it. I don't see any stray frames, but in order to baseline behavior I'd have to deliberately open up my switch and test it.
Quote from: Patrick M. Hausen on August 13, 2025, 09:34:15 PMSounds really niche to me. I want my NMS to know the brands of my components so I can identify devices by that information. If you don't trust your NMS you might have a problem.
I don't have production deployments to manage. I'm a home user and will lose nothing valuable if I spoof the MAC. UniFi anyway already doesn't recognize the gateway. It tells "Third party gateway" in the dialogs and lists the device by its hostname/MAC with a generic icon. Nothing lost or gained either way from what I can see?
The broader goal is more important than the specific example because the NMS is not the threat. The "threat" is the act of giving more information out than is strictly necessary,
on principle.Yes I know how crazy this sounds because the network is full of machines that are the primary vectors of attack anyway, and who cares what the brand of the router is? Well, someone (https://thehackernews.com/2024/02/us-feds-shut-down-china-linked-kv.html) with a list of zero-days might still find the information helpful in narrowing down the ones to deploy.
Quote from: pfry on August 13, 2025, 10:24:44 PMYep, same here. I simply have the main interface "assigned" - didn't bother to unassign it. I don't see any stray frames, but in order to baseline behavior I'd have to deliberately open up my switch and test it.
I'll experiment with assigning the parent interfaces as well. One downside that I see already is that they get listed in netflow/insight and traffic is double-counted. The parent seems to show the sum total of the child VLANs' traffic.
Quote from: OPNenthu on August 13, 2025, 10:37:24 PMThe parent seems to show the sum total of the child VLANs' traffic.
Yes. Unsurprisingly ;-)
R.I.P Lobby pie charts. 2024-2025.
You were meaningful for a time.
:-)
Quote from: OPNenthu on August 13, 2025, 10:37:24 PM[...]
One downside that I see already is that they get listed in netflow/insight [...]
Deselect it? ("Reporting: NetFlow" -> "Listening interfaces") What am I missing?
Heh. I use bridges, and as I recall netflow did not count member interfaces. Although now I'm not certain... Hm. Apparently it sorta works. What the heck, I'll gather some data and see if it makes any sense.
Quote from: pfry on August 14, 2025, 02:47:16 AMDeselect it? ("Reporting: NetFlow" -> "Listening interfaces") What am I missing?
Does yours work differently than mine? The parents are already deselected in Netflow but they still appear in the stats. This is even after a fresh reboot.
EDIT: I didn't notice earlier, but the WLAN_* interfaces are not even listed in the available listening interfaces list (it only has the VLAN_* ones), but somehow they are all reflected in the pie chart. I figured this one out (error on my part).
<tangent>
I'm currently re-doing my network and experimenting with breaking out my WLANs separately from the wired ones, on different links. Not sure how it will work out (TBD).
</tangent>
I do not have the parent of my VLANs assigned and it does not appear in the Netflow data that OPNsense sends to ElastiFlow.
Quote from: pfry on August 14, 2025, 02:47:16 AM[...]
Heh. I use bridges, and as I recall netflow did not count member interfaces. Although now I'm not certain... Hm. Apparently it sorta works. What the heck, I'll gather some data and see if it makes any sense.
Replying to myself: Apparently VLAN bridge member interfaces gather (some) data, and plain interface bridge members do not (when selected). And one bridge and one unidentifiable (null or cut off identifier in the graph) interface that were not selected did appear in the graphs.
At any rate, netflow still doesn't do what I want. I'm holding out for real pf logging. I'm also waiting for a giant pile of money to fall into my lap.
I have a single LACP bundle connected to my switch infrastructure and all interfaces but WAN as VLANs on to of that. WAN is a 1G port plugged into the DSL modem.
Netflow works perfectly as expected in that configuration.
It just took me a while to find ElastiFlow as a potential candidate, then find the time to install and configure. It was clear to me from the start that I do not want to log locally on the OPNsense device.
That was my previous setup as well: LACP parent (lagg0) with VLANs and the parent was unassigned.
Now I'm not using the lagg IF but instead have 2 separate VLAN trunks on igc2 & igc3 respectively. Just as before, as long as the parent(s) are unassigned in OPNsense then they do not get reflected in NetFlow stats.
However- once parents are assigned & enabled (such as to spoof the MACs at the parent level), then I'm noticing that those parent IFs automatically get counted in NetFlow. This happens even though the parents are unselected for NetFlow collection in Reporting->Netflow. It happens even if the parents are disabled (but still assigned). The only way to not have the parents counted is to unassign them in Interfaces->Assignments.
Kind of strange and it doesn't align with @pfry's observation, where apparently he was able to stop collection for the assigned parents simply by deselcting them in Reporting->Netflow.
Quote from: Patrick M. Hausen on August 14, 2025, 05:26:08 PMIt just took me a while to find ElastiFlow as a potential candidate, then find the time to install and configure. It was clear to me from the start that I do not want to log locally on the OPNsense device.
I may look into that when I get a NAS (hopefully a new, cheaper TrueNAS Mini is coming at some point- and with AVX instruction set needed by MongoDB). Though tbh even with Netflow collected locally, my disk usage on OPNsense has remained at 1% (of 256GB) for a very long time now and doesn't seem to grow at all. I think Netflow is cycling data and only keeping a limited time range. The disk space is mostly wasted in OPNsense, unless there's a setting somewhere I haven't discovered yet to extend the retention period.
Quote from: OPNenthu on August 14, 2025, 10:31:30 PM[...] doesn't seem to grow at all. I think Netflow is cycling data and only keeping a limited time range.
Correct, but the writing itself is bound to ruin your SSD ...
About 20 years if the trend holds...
smartctl 7.5 2025-04-30 r5714 [FreeBSD 14.3-RELEASE-p1 amd64] (local build)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF SMART DATA SECTION ===
SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning: 0x00
Temperature: 42 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 3%
Data Units Read: 320,117 [163 GB]
Data Units Written: 9,553,141 [4.89 TB]
Host Read Commands: 10,942,867
Host Write Commands: 134,320,113
Controller Busy Time: 977
Power Cycles: 110
Power On Hours: 6,224
Unsafe Shutdowns: 28
Media and Data Integrity Errors: 0
Error Information Log Entries: 1,286
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Temperature Sensor 2: 52 Celsius
That SSD was newly installed in Nov. 2024, so even rounding up the consumption rate is probably <5% per annum. This is probably where all the spare capacity helps.
I'm assuming the decay will continue on a linear trajectory but only time will tell. Knowing my luck I'll have a failed disk by this time next year :)