I’ve previously designed some networks using the 10.0.0.0/8 address spaced based on the intuitive subnetting it allows for.
e.g.
Site A
10.1.0.0/16
Site A VLAN 1 10.1.1.0/24
Site B
10.2.0.0/16
Site B VLAN 1 10.2.1.0/24
The netmask is also intuitive here when creating firewall rules, 10.0.0.0/8 allow all, 10.2.0.0/16 allow all on Site B or 10.2.1.0/24 allow all on Site B VLAN 1.
Rather than let’s say 192.168.0.0/22 for Site C where I could have four /24 subnets from 192.168.[0-3].0 but I have to rely on software or pen and paper to get the mask correctly (allow all Site C netmask 255.255.252.0).
On the flip-side however is interoperability, let’s say I have a location with mobile access and the carrier NAT is more likely to use the 10.0.0.0/8 address space, or a VPN is used by a guest or to a third party, either from a host or from a firewall and at this point we can run into conflicts. Considering this a subnet space like 192.168.0.0/16 with the exception of 192.168.[0,1,100].0 to avoid home users makes more sense if you don’t need all addresses,
If I was to use some psychological approach I know some companies are in 192.168.0.0/16, perhaps in part as this is the range most junior technicians will gravitate to and thus the 172.16.0.0/12 space might be least utilized?
I suppose I’m wondering about the trade off that can be made between convenience/efficiency/readability and interoperability. What ranges do you use, smallest one necessary or do you paint with broad strokes and go with efficiency/readability when you allocate addresses?
I’ve seen 172.16 get used internally by cell phone operators, and lots of bigger corp environments that have multiple offices.
Lots of residential CGNAT deployments actually do follow the standard to use 100.x.y.z
Any kind of split tunnel IPv4 VPN is doomed to fail sooner or later for someone.
Maybe try:
For psychological model: interface names in firewalls. It’s probably a good practice anyway, since using non-locally connected IP ranges means you need to trust two network devices instead of one to both not do funny network business.
Use ipv6 internally for as much stuff as possible. You can probably get a useful piece of address space.
Not relying on VPNs in the first place and use web apps as much as possible - things like Authelia that you can run in docker alongside whatever is your ingress proxy make 2FA easy peasy.
ipv6 also makes SMB over the internet relatively easy (fat air quotes). As you know file sharing over samba happens over port 445 which is blocked by most ISPs for good reasons. But, since you have infinite local IPs; you can deploy a hosts file on each client (or even do DNS if you feel creative) that points to a local ip, and then use stunnel and TLS to port forward file sharing connections over the internet securely in a mutually authenticated way that’s easy to understand - you still get whatever auth you’d normally use for your server resources over that. To do this server side, you only need a single port that’s accessible for any geographical location where you have a file server, since you can use SNI to differentiate endpoints - physical samba/windows servers.