Secondary IP range on interface

[cybermaus]

Hello


I would like to have a secondary IP address & range on the same LAN interface.
While I would prefer it to be a full VLAN, there are reasons why it cannot be, it has to be on untagged LAN


I made it work by adding a Virtual IP range to the Firewall, and almost all is working as I like.
Except I would like to have hardcoded DHCP leases for this secondary range for specific MAC devices. (In fact, the entire secondary range is for IoT devices, that I can thus easily block or temporary open from the internet, but many IoT devices are not VLAN tag capable.).

And that is where I struggle. The DHCP server only allows the primary address range.

So I would to add the secondary address, somehow, as a n actual interface on the same untagged NIC, or something like that.
Alternatively, I would like to trick the DHCP server to serve leases for specific MAC to addresses outside of its normal range.


Any suggestions?

[bartjsmit]

You will get little protection from IoT snooping and malware by running two subnets on the same L2 broadcast domain.

VLAN or firewall protection is the best way to go. If your OPNsense has sufficient interfaces, you can run a separate WiFi access point for devices you don't properly control (IoT, guests, etc.).

More elegant is to use managed switches with VLAN's and multi-SSID WiFi gear. They'll be more expensive but not massively so. TP-Link SG105E and Unifi UAP make good starting points, although you can go a bit over the top: https://arstechnica.com/information-technology/2018/07/enterprise-wi-fi-at-home-part-two-reflecting-on-almost-three-years-with-pro-gear/

Bart...

[cybermaus]

Somewhat agreed, but I want to avoid this to become a discussion on security.
Any suggestions on how I could achieve the alternate address DHCP serving?

After all, ignoring the why, I can add the Virtual-IP range to the system, so why not serve it too.

[bartjsmit]

I'm not sure how you would determine which DHCP server issues an offer to a new device - IoT or not. You would have to create a reservation for the devices you want to have separate firewall rules for, and create bespoke rules for each.

Bart...

[cybermaus]

Correct, that is what I meant to ask, sorry if not clear.

All DHCP requests go to the normal IP range.
But specific known MAC addresses if programmed, go to a hard IP address. This is also already normal function.
Just in my desired case, that IP happens to be outside of the normal pool, and part of the net that is addressed by the Virtual IP.

I can already select the MAC and add an IP address, it just will not let me serve an address from the Virtual IP range. I used to have OpenWRT, where this was less of an issue. Not that I want to go back or anything.


Alternatively, I guess I could also simply refuse to serve that MAC address completely, and have a secondary DHCP server by means of a small extra OpenWRT server, to server only those MAC's, but that would be an extra server, seems like just an extra thing that can fail.

[bartjsmit]

Just in my desired case, that IP happens to be outside of the normal pool, and part of the net that is addressed by the Virtual IP.

Why do the IoT devices need a separate subnet?

I would set aside, say a /27 at the top of your regular subnet if you're looking for common firewall rules. As I alluded to before, you implicitly trust the IoT devices to play according to the rules; i.e. no MAC or IP spoofing, no rogue DHCP server, no promiscuous mode, etc.

Bart...

[cybermaus]

Making a larger subnet and then splitting it into virtual smaller subnets did cross my mind.
But I was hoping there was an cleaner and easier option. As mentioned, we can add a Virtual IP network, why not simply be able to serve it?


At the danger of making this into security discussion, and thus distracting from the question of 'how', turning it into a debate on 'why', I will argue you the following
(please let that not dissuade anyone from assisting about the 'how' I could most easily do this)


In its core, you are correct. When you claim that a VLAN is best, and a shared Ethernet domain is far from ideal. But it is not true that its black and white. Doing something in the middle has some value.

To build a separate VLAN, I would have to replace not one, but a small dozen of small distributed switches. At €50 each (for a fairly cheap one) that starts to add up. Also, documenting and managing all those individual ports individually is not very desired. As well as adding yet another dozen of IP managed devices.

Spoofing, sniffing, promiscuous mode, are all things that can be expected from non-trusted devices. Mostly however, botnets are used not as spies but as slaves to do DDos attacks and cryptomining.
That is not useful if the device can then also not talk to the outside world. Arguably even spying is not useful unless reported to some agent in the outside world.

Not that it cannot be done, as I am sure you will argue. Its actually pretty simple, because all the needed routable info is in sniffed DHCP packets to other clients. But I think this is not common practice yet. So statistically, by not giving a IoT malware agent a gateway, you crippled it. Statistically.


So in principle you are correct. But there is some value to putting IoT on a separate non-routed subnet. It surely is a hell of a lot better then putting it on your normal subnet and even port forwarding it, or dropping it on the cloud, because of the handy app it came with. As happens by the vast majority of consumers, so malware writers are not even interested in adding extra footprint for extra smarts.

So, if your argument is: A separate VLAN is best, then you are correct. If your argument is: You are not doing a VLAN, so you may as well not do anything, then I disagree.