MAC address change on unassigned parent interfaces

[OPNenthu]

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?

[patient0]

You cloud keep the parent interface enabled but not configured. That way you can spoof the MAC address on it.

[OPNenthu]

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.

[OPNenthu]

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:

Go 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!

[pfry]

[...]
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.

[OPNenthu]

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:

🔍 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.

[schnipp]

[...]
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.

[OPNenthu]

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.

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.

[Patrick M. Hausen]

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.

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.

[pfry]

[...]
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.

[OPNenthu]

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.

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 with a list of zero-days might still find the information helpful in narrowing down the ones to deploy.

[OPNenthu]

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.

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.

[Patrick M. Hausen]

The parent seems to show the sum total of the child VLANs' traffic.

Yes. Unsurprisingly ;-)

[OPNenthu]

R.I.P Lobby pie charts.  2024-2025.

You were meaningful for a time.

:-)

[pfry]

[...]
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.