[HOWTO] Plan your IPv4 subnets in advance!

[meyergru]

I urge every new OpnSense user to carefully plan their subnets - preferably in advance. While this seems obvious or "easy", the devil lies in the details, some of which you may not know or anticipate.

Of course, if you know anything about networks at all, you will have heard about RFC1918.
This standard defines IPv4 ranges that are to be used on local networks and will not be routed into the open internet, thus needing a NAT translation.

There are three available ranges, namely 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8. You might think, well fine, let's just use one of those, but wait...

By convention, the 192.168.0.0/16 range is almost always divided up into smaller /24 subnetworks - and you should do the same. There are some reasons for that:

• If you want to use larger ranges, because you need more than 254 clients within one subnet, think again:
  - More than about 200 clients in one subnet will cause a significant amount of broadcasts. Not only for ARP, but also for proprietary protocols that many IoT and smart devices use. While modern ethernet with full-duplex is nice, it does not help for broadcasts, let alone what broadcasts do on wireless networks (consider separating them from your (V)LANs).
  - Also, you should at least split up your network into several VLANs based on the trustworthiness of your clients by type: Do they "phone home"? Then put them into a separate VLAN! This alone will probably result in less than 200 devices per VLAN/subnet.
  
• If you want to use smaller ranges, take care. For example, you may think that for accessing your modem, which has an 192.168.100.1 address, you could use a very small network containing only two adresses (thus with a netmask of /31), you would be wrong to choose 192.168.100.2 on your WAN interface. Think about why (use a network calculator if needed).
  This example provides two insights:
  a) A netmask of /31 is always wrong, because usually, you have at least a "network", a "broadcast", a router and one client address, therefore you need a /30 netmask at least and
  b) anything apart from a /24 netmask is hard to visually get correct. /24 netmasks are easy to deal with for humans, because their 3rd octet is always the same, so you can see if two IPs belong to the same subnet (hint: 192.168.100.1 and 192.168.100.2 do not lie together in any /31 subnet).
  
• In fact, anything apart from a /24 subnet in the 192.168.0.0/16 range is considered "unconventional" - and if not explicitely stated, will not be implicitely assumed by anyone trying to help you. This may lead to much wasted time while troubleshooting.

If you really need to configure netmasks different from /24, please do so in the 172.16.0.0/12 or 10.0.0.0/8 range. Because these are more often used by businesses or big enterprises, there a lot less assumptions for those.

Another hint:

Do not use 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 192.168.88.0/24, 192.168.100.0/24 or 192.168.178.0/24 for your (V)LAN subnets. This is why:

Those ranges are often the default for many routers, including OpnSense itself. Most people, who often know jack about networking, leave their routers at their default settings. At some point in the future, when you try to build a Wireguard site-2-site VPN to a friend, you will find that one of you has to restructure their whole network to be able to route anything at all. Depending on the complexity of the network, this may be hard task. Also, many ONTs, cable and DSL modems use IPs from these range. If you want them to be made accessible on the WAN interface, you must not have the same range in one of your own (V)LANs. And finally, those ranges are often used by devices in their default state, which may conflict with your network when you connect those.

[passeri]

... or 192.168.88.0/24

In fact you could do worse than going straight to 10.x.x.0.24 where you generate the second and third octets randomly (once!).

meyergru's advice deserves further emphasis. A written IP plan will not only save trouble as described, it will also help you see what you really have when you come back to change your network months later. It will make fitting in new parts or systems much easier.

[meyergru]

I added 192.168.88.0/24.

Using any of 10.0.0.0/8's subnets can have an adverse effect when your employer is a big enterprise and uses that, too: try working from home via VPN... (been there, done that) ;-)

[Patrick M. Hausen]

RFC 1627 😉

[meyergru]

Two "war stories" you may find amusing w/r to "10" networks, which show how even that seemingly large network poses unforeseen problems...

1. In the mid 2000s, when I worked at SKO (Sparkassenorganisation - the organisation of federal banks in Germany), they had connected all their national networks and gave every state datacenter its own /8 range, 1.0.0.0/8 to 16.0.0.0/8. That is when I came in and had to implement internet access for all branches in one federal state. Its datacenter happened to be the one who had been assigned 10.0.0.0/8. Lucky me - the other datacenters had some restructuring to do... (we were speaking about planning ahead of time!)

2. Siemens uses the 10/8 network internally as well. As a matter-of-fact, when I worked there, they had >200.000 employees worldwide at that time and even more IPs. I worked in a department whose sole responsibility was the IP address mangement via centralized DHCP servers using DHCP relaying to their smart switches. There was a hand-build application and an IPAM database. IPs were so scarce that they often had to stick together disjoint ranges when IPs became exhausted in local networks. They also used short lease times to free up unused IPs earlier. In fact, the scaling factor was so huge that once they relocated of of their DHCP servers, we even identified a problem in the logging of requests (!) - the database could not keep up with the number of log entries being generated because of a network delay of 25ms to one server. I developed a patch for FreeRADIUS, which is probably still in existence today.

[Patrick M. Hausen]

UHU GmbH & Co. KG, well known manufacturer of various glues, belongs to an italian holding. They acquired a dutch glue manufacturer called Karlsons Klister. Both companies used net 10 extensively. And of course not in a way to structure/subnet, but to use the various octets for semantic encoding of extra information - department numbers, machine type ...

Getting two Windows domains to build a trust relationship across two Fortigate firewalls with double NAT and DNS translation and an IPsec tunnel was "fun" 😬

[meyergru]

These days, you probably should let ChatGPT do that for you, Patrick! Then again, it's less fun! ;-)

[OPNenthu]

Great info here -

While modern ethernet with full-duplex is nice, it does not help for broadcasts, let alone what broadcasts do on wireless networks (consider separating them from your (V)LANs).

The OPNsense guide on Security Zones has an example where they also put the WiFi networks on separate VLANs from the perspective of trust.  You raise a good point about WiFi performance as well.  Both sound like good enough reasons to look into doing this on my home network.

I'm assuming that if we are using IPv6 PD with the 'Track Interface' setting, then we'll have to assign unique interface IDs for the WiFi networks and consume IPv6 range as well?  In that case my ISP's /60 delegation is still viable but now starting to feel uncomfortably small.

- Also, you should at least split up your network into several VLANs based on the trustworthiness of your clients by type: Do they "phone home"? Then put them into a separate VLAN!

Is there anything that doesn't phone home these days? ;)  I can no longer tell the difference between my "trusted" home PC and a smart kitchen appliance, except for their intended use.

Maybe it's better to isolate by use case.  My refrigerator doesn't need access to my tax returns, even though my PC betrays my trust just as much (if not more).

I'm generally struggling with the zone concept of "trust" vs. "untrust" as nothing seems to fall into "trust" anymore.

Of course, if you know anything about networks at all, you will have heard about RFC1918.
This standard defines IPv4 ranges that are to be used on local networks and will not be routed into the open internet, thus needing a NAT translation.

[...]

Also, many ONTs and DSL modems use IPs from these range. If you want them to be made accessible on the WAN interface, you must not have the same range in one of your own (V)LANs.

Cable modems, too.  My ISP modem in bridge mode uses 10.0.0.1 (non-configurable) for the admin UI.  I don't have any such route in OPNsense, nor is the modem MAC listed in the ARP table, so it must be using outbound NAT to let me reach the modem UI I presume.

This raises a concern, besides that I should not use this 10.x range for a VLAN:

Does it make security sense to add a rule (either as a Floating rule on internal interfaces, or a WAN outbound / post-NAT rule) to restrict which RFC1918 destination addresses are allowed out through NAT?  My modem happens to respond to 10.0.0.1 but what if some client tried to reach another private address through the WAN and a rogue device (or a neighbor) was listening on it?

[meyergru]

I'm assuming that if we are using IPv6 PD with the 'Track Interface' setting, then we'll have to assign unique interface IDs for the WiFi networks and consume IPv6 range as well?  In that case my ISP's /60 delegation is still viable but now starting to feel uncomfortably small.

Of course, if you define VLANs, then any one of them needs its own locally routed subnet. Since the minimum possible IPv6 subnet is a /64, you will have to use this. With a /60 delegation, you can define 16 IPv6 subnets at most. You could have VLANs without any IPv6 at all, however, like for a MGMT VLAN discussed later.

Is there anything that doesn't phone home these days? ;)  I can no longer tell the difference between my "trusted" home PC and a smart kitchen appliance, except for their intended use.

Maybe it's better to isolate by use case.  My refrigerator doesn't need access to my tax returns, even though my PC betrays my trust just as much (if not more).

I'm generally struggling with the zone concept of "trust" vs. "untrust" as nothing seems to fall into "trust" anymore.

I did not say anything about the logic behind the separation of "trustworthiness" at all, but you hit the nail. For example, my LAN is the "security realm" where I keep my data (NAS, PCs, Laptops), whereas I put SmartTVs and IoT devices in another trust realm. I also have my HomeAssistant and another (logical) Media-NAS in that realm. Obviously. IoT devices need to talk to HomeAssistant, but I could separate SmartTVs and the Media NAS into another realm, but I would only do this when the "level of trust" was different. This is the case for my DMZ, because the explicit access from outside makes this a special case, IMHO.

Cable modems, too.  My ISP modem in bridge mode uses 10.0.0.1 (non-configurable) for the admin UI.  I don't have any such route in OPNsense, nor is the modem MAC listed in the ARP table, so it must be using outbound NAT to let me reach the modem UI I presume.

This raises a concern, besides that I should not use this 10.x range for a VLAN:

Does it make security sense to add a rule (either as a Floating rule on internal interfaces, or a WAN outbound / post-NAT rule) to restrict which RFC1918 destination addresses are allowed out through NAT?  My modem happens to respond to 10.0.0.1 but what if some client tried to reach another private address through the WAN and a rogue device (or a neighbor) was listening on it?

Duly noted.

And yes, of course you should control which devices can access your ONT/modem. Usually, that outbound NAT rule for the WAN VIP must be manual anyway and you set a source network in that. If you do not have a management network yet (I do), then you should at least have a firewall alias "MGMT clients" on your LAN (it could list IPs or MACs), which can be used instead to limit access. This is also following the "level of trust" rule discussed before, which is obviously influenced most by application and data confidentiality.
In enterprise contexts, you would really have a trusted management VLAN, but in my small world, I do not want to afford a separate management workstation. Since my PC is normally on the LAN, there is a rule allowing access for my "MGMT clients" on the LAN to the MGMT VLAN, which contains OpnSense, my switches and my Unifi controller (Yep, those are not on the LAN, which by now should be clear).

Apart from that, I also use an "out" rule for anything RFC1918 but the ONT/modem on my WAN, because with the default gateway on WAN, you will leak any local RFC1918 IPs that are not locally defined. My ISP reacts to those leaks by disconnecting for a few seconds, and since then, I do this for good measure. You have to be careful to place an "allow" rule for your ONT/modem before the "block" rule for outbound RFC1918, though.