I've been really careful about selecting virtual network IP spaces throughout due to this concern.
The hardest part is accounting for the point-to-site VPNs on top of everything else (i.e. employees connecting from home/Starbucks/airport).
For internal corporate networks, I typically will provision smaller targeted networks in order to get around this. Lopping-off all of 10.0/16 or 192.168/16 for your internal LAN will put you at a fairly high statistical likelihood of overlapping domestic ISP address spaces. Smaller, odd networks like 192.168.111/24 are much easier to plan around.
For virtual network IP space you can go with the 0.0.0.0/8 space (sometimes called "zeronet") as long as you are using kernel 5.4+ everywhere you want that network. Obviously 0.0.0.0/32 is still excluded.
Windows (and probably macOS?) still block that as of today so it can be an extra safe (and large) space if your only worry is "I don't want my virtual network space to collide with outside or client sourcing networks".
I ran into this problem a long time ago with EKS. I picked a network for EKS, but it also needed a network for docker running on each node, and this happened to conflict with a network that we had peered to AWS (we were an ISP, this was our internal management network).
I learned on that day to put everything in our IP address management system (netbox). Allocate private networks like we allocated public networks to our customers. (It would have been nice if I allocated Docker's defaults before they had been allocated to an internal network, but ... hindsight 20/20. At least with that network in the IPAM system, people could figure out why it broke though.)
I have had this happen with Docker compose too in a much less complicated setup.
When you add a network, it gives you a network. It allocates a pretty big address space each time, and eventually it'll run out of 172.16.0.0/12 space and move on to 192.168.0.0/16 networks.
Why can I get to this from the guest network but not the client network? Oh...
It sucks, but I manually set networks now. And keep track of them.
Ah what a fun issue to figure out and resolve 10 minutes before endofday,especially if you are the one handling docker and some dude in another country is handling the vpn that wants access to said docker.
I've been really careful about selecting virtual network IP spaces throughout due to this concern.
The hardest part is accounting for the point-to-site VPNs on top of everything else (i.e. employees connecting from home/Starbucks/airport).
For internal corporate networks, I typically will provision smaller targeted networks in order to get around this. Lopping-off all of 10.0/16 or 192.168/16 for your internal LAN will put you at a fairly high statistical likelihood of overlapping domestic ISP address spaces. Smaller, odd networks like 192.168.111/24 are much easier to plan around.