For bigger networks, I always went with 10.0.0.0/8 for endpoints, 172.16.0.0/12 for servers and other back-end services, leaving 192.168.0.0/16 for smaller networks like OOB IPMI (eg HP iLO, Dell iDrac) services, cluster heartbeat connections, and certain DMZ segments.

[–] ramble81@lemm.ee 3 points 4 months ago* (last edited 4 months ago) (1 children)

That’s doable too. A lot of people don’t realize you can route all of those together. It’s even more fun as technically you can route private addresses across public links if you own both ends of the link. Used to see that done at a large ISP to route their internal network and it’d pop new networking admins minds.

ETA: I would use 192.x IPs for unrouted subnets like heartbeats or iSCSI.

[–] Natanael 1 points 4 months ago* (last edited 4 months ago)

Common to see big businesses with multiple locations using P2P VPN binding together all sites like one big LAN. Perhaps not ideal from a security standpoint to have the client network so flat, but eh 🤷

Usually a handful of extra important servers are behind an extra layer of firewall rules and/or on a different VLAN with limits on what devices can connect to them.

[–] Trainguyrom@reddthat.com 3 points 4 months ago

My current work acquired a company with a very poorly provisioned IT department. Their networks all happen to be in the low 192.168.0.0/16 so users VPNing in often end up with wonky IP conflicts. I've heard warnings about similar when selecting subnet ranges, so I just stick with low 192.168.0.0/16 ranges for home networks from which I might potentially VPN into a network I don't control, and I use 172.16.0.0/12 or 10.0.0.0/8 at work as needed and as aligns with our wider topology.

I will also add that I encountered some fun challenges at a small bank I worked at where they clearly under-planned their network and carried a bunch of wonky configs as vestigial networking adaptations as they grew. They did do a cool thing where they made each branch its own /24 subnet so you could tell at a glance exactly what branch someone was connecting from, plus branches could theoretically limp along with an ISP outage, but they didn't the extra steps of setting up edge servers so the end result was a full branch outage during an ISP outage