I recently just changed my default subnet to 10.X.Y.... rolling two random numbers to make it highly unlikely my home subnet through wireguard would conflict with the subnet where I am connecting from.

▲

pcarroll 13 minutes ago | parent | next [-]

This works fine for your end. But the issue we are addressing is on the other end, when you don't control the network and need to reach devices. If all customer sites are running rfc-unroutable blocks, you eventually encounter conflicts. And the conflict will likely be with the 2nd one you try.

▲

trollbridge 2 hours ago | parent | prev [-]

I just use /24s in the lower-middle range of 172.16. Very unlikely to have a conflict there.

▲

OptionOfT 22 minutes ago | parent | next [-]

Do you run Docker? Because I remember having to VPN out to a client that used that range, and it caused conflicts where our docker containers couldn't reach the client side to fetch data.

Docker defaults to 172.16.0.0/16.

	▲	pcarroll 8 minutes ago \| parent [-]
		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.

▲

dmd an hour ago | parent | prev | next [-]

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.

▲

dijit an hour ago | parent [-]

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.

	▲	x0 an hour ago \| parent \| next [-]
		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
	▲	pcarroll 35 minutes ago \| parent \| prev [-]
		I actually looked at using those before the CGNAT range, but many of those blocks have been returned to the public Internet.

▲

pclmulqdq an hour ago | parent | prev | next [-]

I often use 172.31/16 for subnets and have never seen a conflict. I have seen 172.24 and 172.16 used before, though.

▲

EvanAnderson an hour ago | parent | prev [-]

I find a lot of Docker containers using subnets inside 172.16.0.0/16.

	▲	notpushkin an hour ago \| parent [-]
		Probably for the same reason – 172.16/12 is not as widely used for other networks :-)