Comment by trollbridge
Comment by trollbridge 4 days ago
I just use /24s in the lower-middle range of 172.16. Very unlikely to have a conflict there.
Comment by trollbridge 4 days ago
I just use /24s in the lower-middle range of 172.16. Very unlikely to have a conflict there.
When I separated my scientific instruments from IT, I went to fixed IP and set each device to 192.A.B.x where x is different for each instrument or PC. And A & B are for my lab only, but definitely not the same as the "generic" address range IT is using.
One day somebody working days or nights "helpfully" plugged one of IT's loose office-machine-network cables into one of my little lab ethernet switches which had a vacant spot :\
With separate IP subnets it really kept the traffic from crossing, no damage was done, and nobody ever knew until a PC configured for DHCP was plugged into the lab network, and their router wanted to autoassign an IP address to it.
So, uh.
I kinda don't want to share this because:
A) it's a bad idea
B) it means it will be less unique
and
C) I got teased for it a long time ago by my other nerd friends.
But the US DOD has huge blocks of prefixes that it doesn't do anything with, presumably they use it for internal routing so every device they have could publicly route without NAT..
One of those prefixes is 7.0.0.0/8.
My home network uses that. I have never had an issue with S2S VPNs.
However, there have been a few bits of software (pfsense for example) which have RFC1918 hardcoded in some areas and treat it like a public network and overwriting it means doing the entire network setup manually without the helping hand of the system to build-out a working boilerplate.
In this vein there's also 3 TEST-NETs, all /24 but still useful. I've been known to use TEST-NET 1 for Wireguard: 192.0.2.0/24. The other two are 198.51.100.0/24 and 203.0.113.0/24.
There's also 198.18.0.0/15, Wikipedia says it's "Used for benchmark testing of inter-network communications between two separate subnets"[1]. Use this if you really want to thumb your nose at the RFC police.
[1] https://en.wikipedia.org/wiki/List_of_reserved_IP_addresses
We chose Go as the development language. Go produces statically compiled binaries that include all dependencies. The only external deps are wireguard, nftables, nmap, etc. All easy stuff. So we have no need for Docker. We publish binaries for ARM64 and AMD64. Avoiding Docker has made it much easier to work with.
I had this happen at home. I'm not convinced it was a good idea to choose default subnets as /20.
It was pretty easy to cause myself problems with Docker compose. Eventually I run out of subnets in the 172.16 range and it happily created subnets in the 192.168. range. Some of them overlapped with subnets on my LAN.
Yes, we use Docker (or podman) but generally never rely on Docker’s internal address ranges.
I find a lot of Docker containers using subnets inside 172.16.0.0/16.
Probably for the same reason – 172.16/12 is not as widely used for other networks :-)
My (very large) corporate network uses 172.16 and 10. heavily, which has lead me to set my docker/daemon.json default-address-pools to 84.54.64.0/18, as it's very unlikely we need to communicate with any IPs in Uzbekistan.