newb question: network config

[ts12b]

I'll put my flame suit on, but please try to be gentle...I'm a hobbyist, not an IT guru.  I'm currently a pfSense user, looking to make the switch, and as such, now is as good a time as any to make the changes I probably need to make.  Current network config is as follows:

192.168.1.XXX is for wired devices
192.168.3.XXX is for wireless devices (many, if not most of which have static IPs assigned by DHCP)
10.10.10.XXX is for devices related to only security cameras and the server that runs the cam software and stores the footage.

I'm probably going to be moving to a network video recorder and ditching the software, but I would still like to keep camera access air gapped and not internet accessible.  The cameras have static IPs configured in the cameras themselves.

I would prefer to keep wireless devices and wired devices on their own subnets, but obviously able to communicate seamlessly on the network.  Each of those would still have DHCP, although most would still be statically assigned through DHCP.

So, let the suggestions (or criticisms!) fly and ask questions if you need to.

[Patrick M. Hausen]

And your question is? Looks like a perfectly viable network setup.

[ts12b]

And your question is? Looks like a perfectly viable network setup.

Well, since I have not yet set up OPNsense, I'm basing my experience on pfSense, and pfSense won't let me apply a subnet mask that crosses over the subnets.

[Patrick M. Hausen]

You did not state which subnet mask you intended to apply so from the .XXX I infered you were going to use /24. Of course. No firewall will let you use subnet masks that span interfaces because IP does not work that way. The networks on your interfaces must be disjunct.

[ts12b]

You did not state which subnet mask you intended to apply so from the .XXX I infered you were going to use /24. Of course. No firewall will let you use subnet masks that span interfaces because IP does not work that way. The networks on your interfaces must be disjunct.

And maybe that's the source of my confusion.  So what's the cleanest way to accomplish what I've set out in my original post?

[Patrick M. Hausen]

3 interfaces or 3 VLANs with the IP addresses exactly as you outlined and each with a /24 netmask.

[ts12b]

3 interfaces or 3 VLANs with the IP addresses exactly as you outlined and each with a /24 netmask.

But then that won't allow a desktop on 192.168.1.XXX to communicate with a wireless device on  192.168.3.XXX.....

Am I missing something?

EDIT:  Ideally I'd like the mask to be /16, but as you said, this can't happen across interfaces.

[Patrick M. Hausen]

Then use just a single interface with a /16 netmask. Assign the addresses to the devices as you see fit if you just want to "sort" them in some way.

[ts12b]

Then use just a single interface with a /16 netmask. Assign the addresses to the devices as you see fit if you just want to "sort" them in some way.

Thanks for your input, but it's not helpful.  I'm really dumbfounded that what I'm trying to accomplish is going to require me to manually assign a bunch of parameters, which defeats the purpose of DHCP, don't you think?

[Patrick M. Hausen]

Use a /16 netmask and DHCP of course. You can use e.g. 192.168.0.0/16 and assign 192.168.1.2 to one device and 192.168.3.5 to another one all via static DHCP reservations.

What do you want to achieve at all? If you want to separate your regular and your IoT devices in any meaningful way, you need separate interfaces, separate metworks and DHCP on each interface, of course.

If you just want one large network, the go ahead and do so. There's nothing special about a /24 or a /16 size network, you can use them as you see fit.

Separation and control requires different interfaces. All devices connected to a single interface can communicate with each other without the firewall even being involved. So a /16 rules out separation. Multiple /24 allow for separation. What is the reason why you would not want the latter?

[ts12b]

Because it's really handy to know if a particular device that I don't recognize is wired or wireless....I've got various projects going on, so both wired and wireless devices might be added to the network and assigned some random DHCP address.  I might statically assign those later, or it might be something temporary where I don't care...but I still need to be able to have devices communicate across those subnets.

So, for example, I use a laptop in my office, and it's currently connected wired via the dock.  But if I decide to take it into the kitchen where it will connect wirelessly, then it won't be able to reach my file server (which of course is also wired), because it's now on a different subnet.

Then there's the issue of the security cameras and isolating them from the internet.

How does this work in organizations where lots of network segmentation occurs?  Sysadmins need access to the whole thing (or at least multiple parts of it).  Can I have separate DHCP pools based on some devices connecting through the WAP(s)?  Currently all of the cameras have statically assigned IPs (not through DHCP), and I use two physical NICs in the server that runs the software and manages the footage.

[Patrick M. Hausen]

For company networks wired or wireless is not a matter of distinction. Level of privilege or trust is. Your laptop is the same device whether connected via Ethernet or WiFi so it should be in the same network for both connections.

Your untrusted IoT devices go into a different network. That's what different SSIDs on your APs and a mapping of SSIDs to VLANs are for.

Your DHCP server only sees a MAC address requesting an IP lease, it has no way of knowing if that device is connecting via an AP (in AP or "bridge" mode) or connected directly to the switch.

And for communication across subnets including the fileserver - that's what firewall rules achieve and for autodiscovery possibly an mDNS repeater.

You cannot have different pools on a single network depending on the type of device or connection because OPNsense does not know these things. No firewall does. If you need different policies you must use different interfaces. That's how more complex networks operate. I have 9 VLANs at home "just because I can" with 9 networks, 9 DHCP configurations, 9 sets of firewall rules. Interface groups help a lot so you only need to configure some rules once instead of 9 times.

[ts12b]

Your untrusted IoT devices go into a different network. That's what different SSIDs on your APs and a mapping of SSIDs to VLANs are for.

Ok, now I'm getting a better picture here.

Your DHCP server only sees a MAC address requesting an IP lease, it has no way of knowing if that device is connecting via an AP (in AP or "bridge" mode) or connected directly to the switch.

That I get.

And for communication across subnets including the fileserver - that's what firewall rules achieve and for autodiscovery possibly an mDNS repeater.

Ok, so THIS is the issue.  Maybe OPNsense functions differently than pfSense in this regard (but I doubt it).  I thought that I could simply make firewall rules that would allow traffic between subnets (and therefore interfaces), but this has been spotty at best.  If I connect this laptop over Wifi instead of wired through the dock, I won't be able to reach the wired subnet, despite explicit firewall rules being in place to allow this traffic.  If I reconfigure the wireless NIC to use a manually applied static address and a mask of /16 instead of having these parameters assigned through DHCP, then it works like one would expect.

[Patrick M. Hausen]

You would need to share your interface configuration, your DHCP server configuration, and your firewall rules in detail for any diagnose via the forum about what might have been wrong.

pfSense and OPNsense do behave almost identical in these specific aspects.

[ts12b]

You would need to share your interface configuration, your DHCP server configuration, and your firewall rules in detail for any diagnose via the forum about what might have been wrong.

pfSense and OPNsense do behave almost identical in these specific aspects.

Understood.  I think it's best to get OPNsense rolled out and up and running first.  If the firewall rules are supposed to work, then that should get me to where I want to be.  If not, then I can come back with the detailed info for further investigation.