@benjojo I've sometimes wondered if the best way to avoid this problem is to squat one of the documentation networks. Or the benchmarking one

@erincandescent @benjojo Well… could maybe be used in some testsuites.

@benjojo @erincandescent my "I'm only half joking" suggestion is 240.0.0.0/4, hardly anyone is going to run tests on that

it'll probably work with Linux-based BMCs? has the advantage that Windows hosts politely refuse to send packets there, but has the disadvantage that Cisco routers also refuse to send packets there

@erincandescent @benjojo
Something out of 100.64.0.0/10 would be a somewhat reasonable choice. (avoid 100.100.0.0/16 though as it's the obvious choice)

@nblr @benjojo I would avoid it because you're increasingly likely to get IPs in that space from ISPs

@nblr @erincandescent @benjojo Tailscale uses 100.64.0.0/10 by default, I think.

@neverpanic @nblr @erincandescent @benjojo yes, it does. this can cause weird problems if you're on a network where the dhcp server hands out addresses in that range.

i ran into this a few times and then decided to renumber my vpn to a subnet outside 100.64.0.0/16.

@erincandescent @benjojo some network gear vendors do this for internal stuff lol

@erincandescent @benjojo iirc it was used in sdwan gear (from ekinops)

@benjojo In case you didn't stumble over it already and want to add it to the list, Mikrotik uses 192.168.88.0/24 as default prefix.

@benjojo ok :)

@benjojo The best way to permanently solve this problem is to use an IPv6 subnet for OOB, and simply allocate a contiguous slice of it for "private" NAT64 to any legacy-only devices (vs using the well-known nat64 prefix, which could collide with a local gateway)

@benjojo Clever approach to an issue that's more common than most people think, thanks for publishing the data!

Have you considered the bias of users of obscure subnets not making themselves as easily noticeable from the outside than users of common ones, though? That's to say: wouldn't somebody that actively chose to place their network on a subnet that's among the more deserted ones also be less likely to publicly expose a WD Cloud-like device instead of, for example, using a dedicated VPN to access their LAN-only NAS and thus not showing up in your scans?

@benjojo Absence of conflicts granted by weirdness and pedantry? Sounds like my setup is safe 👀

@benjojo what about using IPv6 for OOB? 😉

@benjojo great writeup, and a fun topic! Looks like my 192.168 subnet is pretty rare.
And my 10 subnet is unused!

@benjojo Interesting methodology to find unused subnets :)

@benjojo Oh, I've recently encountered a setup where use of the lesser known 172.32.… range was made.

@nblr @benjojo at least they *tried* to use some of the lesser used prefixes...

@nblr @benjojo One of my clients has a site-to-site VPN where the other side uses 211.69.0.0/16, and no, that client is not Chinese…

@benjojo tired: using a little used RFC1918 prefix to avoid collisions

wired: using the most widely used RFC1918 prefix for OPSEC reasons

(WebRTC/STUN leak your local IPs)

@benjojo For the third octet in 192.168.0.0/16, 0 and 1 are the common consumer router defaults and 100 is commonly used by cable modems. I roll d256 and if I get one of those three I re-roll. 10.0.0.0/8 tends to be used by corporate systems and rarely by consumer gear so I roll d256 each for the second and third octets and re-roll on 0. It's served me well for decades since CIDR became the norm.

@benjojo not much love for the obvious 192.168.42.0/24 in there

@benjojo by chance I am reading this on a work laptop with a non-rfc1918 IPv4 address.

The upsides of an established university network.

@benjojo

interesting data, but i fixed this by using 198.18.0.0/15 (benchmarking prefix, RFC2544) for my private legacy IP networks:

- it should never be used by CPE because it's not meant for that
- but it can also never be used on the Internet

i suppose this might still break if two people had the same idea, but then fix is to move to IPv6 :-)

@benjojo I personally love my 10.69.0.0/16 space I use for my internal network and 10.0.69.0/24 I use for my VPN. Obviously I'm very mature. 😅

@benjojo That fact WD managed to broadcast something that tells you my internal network space is... not my favorite thing! Thanks for sharing!

@benjojo my solution for this has been to get a randomized /48 ULA prefix on my network and do IPv6-only connections over a VPN, statistically guaranteed to never have a subnet conflict

later I also moved my IPv4 subnet somewhere into the 172.16.0.0/12 space, nice to see that I picked a rare one for that!

@benjojo I love those patterns in 10/8 and how most of them fade away