Alias file bluk update changing device IPv4 addresses to MAC IDs

[RobLatour]

In preparation for a move from an IPv4 only setup to an IPv4 & IPv6 setup, from what I read, it appears it would be a good idea to change all my device aliases from being Host (IPv4 based) to MAC Id based.

The majority of my firewall rules use Aliases, so I'm thinking if I do this and switch the scope of those rules from IPv4 to IPv4+IPv6 then all those rules will apply nicely to both IPv4 and IPv6.

So to get this done, I have downloaded:
- the Alias's json extract, and
- the DNSMASQ DNS & DHCP - Host extract .csv file.

My plan, unless there is already a script out there (hence in part the reason for this post) is to write a script that will create a file I can import (upload) into the Aliases list which contains for all devices aliases a replacement entry that uses:
- an Alias Type of 'mac' instead of 'host' and
- in content replaces the existing IPv4 address(es) with their matching hw_address (mac) from the DNSMASQ DNS & DHCP - Host extract .csv file.

So my questions are:
1. Will this work?
2. Is there already an existing script for this?

[FrancoisMaymil]

Before scripting this, there are two things good to know:

MAC aliases only work for devices on networks directly connected to the firewall, because OPNsense resolves them from its ARP/NDP tables. With IPv6 privacy addresses, the address currently used can change, and the alias will only catch it once it appears in the NDP table. Phones using randomized MAC addresses can also be a problem here.

If your IPv6 prefix is static, I think the most predictable solution is simply to add the IPv6 host entries next to the IPv4 ones in the same alias.

If your ISP prefix can change, have a look at the "Dynamic IPv6 Host" alias type. It combines the current prefix of the interface with a fixed host part, so you don't have to change all aliases when the prefix changes.

For doing the bulk change: in Firewall > Aliases you can export/import the aliases as JSON. So normally you can edit the export (type and content of each alias) and import it back.

I would make a config backup before, and test it first with only one alias before doing all of them.

[nero355]

Phones using randomized MAC addresses can also be a problem here.

That's not a problem at all if you simply do not allow such devices on your WiFi :)

Q : "Hey can you connect me to your WiFi ?"
A : "Sure, give me your Laptop/Phone/Tablet please."
@WiFi Settings of the device =>
- Add Network
- Some kind of "Advanced Options Button"
- Disable nonsense like 'Metered Network' and 'Random MAC Generation'
A : "Here is your device. Have fun!" :)

If they do not co-operate = Have fun with your dataplan! LOL! :P

[RobLatour]

@FrancoisMaymil thanks for the tips!

Yes, I plan to use for the most part static addresses - so I like your idea of:

> If your IPv6 prefix is static, I think the most predictable solution is simply to add the IPv6 host entries next to the IPv4 ones in the same alias.

esp. based on some of your comments + I wasn't sure what to do with the mac ids of vlans anyway.

Thing is once I open up IPv6 on my network I will have a lot of IPv6 addresses to add to my Aliases table.

So maybe I'll write a script all the same, but it will now focus on merging ipv6 ids in with the IPv4 addresses in the exiting Aliases table.

this by:
1. reading the current Aliases extract
2. reading the current downloaded host .csv file (as it will contain the current IPv4 addresses and, I assume the new IPv6 addresses, + their mac addresses)
3. matching the mac id address for the IPv4 and IPv6 form the downloaded host .csv file
4. updating the alias file to include the IPv4 and IPv6 address for the aliases based

And yes I was planning on doing both a config backup and snapshot before uploading anything

If I get this to work I'll post it on github for others.

Thanks again

[RobLatour]

With IPv6 privacy addresses, the address currently used can change, and the alias will only catch it once it appears in the NDP table. Phones using randomized MAC addresses can also be a problem here.

Once again securtiy and privacy meet, pistoles drawn, on the field of honour.