Link-local aka APIPA: 169.254.0.0/16
Be aware Windows won’t route to these IP’s. It won’t send traffic destined to these addresses to its gateway. So very likely you won’t be able to talk to any thing behind that VPN except the internet and internal linux systems since Windows server won’t route the traffic back to you
Reserved ranges is a shout. Probably not something I’d do routinely, but in a desperate situation that’s good to remember.
Hamachi is a name I haven’t heard in a while 
Good old times when you would infect your computer with Lime Wire and shit
Now there’s an idea. And a throwback.
Well, OP never specified anything concrete. For a site-to-site VPNs or mobile phones? Yes that will create problems. For remote work type of VPN? Shouldn’t be that big of a deal.
ISPs usually don’t use that space for any customer-facing/-accessible systems. Using the same space within a P2P-VPN, which is tunneled anyways, really should not be an issue whatsoever.
So, while I do agree that there are better alternatives (hell, even just configuring your VPN client correctly in regards to routing), the argument that using 100.64/10 in a VPN may cause issues with your ISPs CGNAT is completely moot.
The fact that some K8s distributions (including some of the big cloud providers’ managed solutions) default to using CGNAT addressing for service IPs will eventually bite somebody.
People will go to great lengths to avoid learning IPv6.
The addresses should not be the same.
You’re talking about routing not a VPN concentrator.
How do ppl in office X communicate with office Y in a different country
You turn your laptop on.
Do you then use a client to connect like AnyConnect? Or does your firm connect you automatically with a client like Zscaler/netscope/Palo etc.
When you’re tunnelled in you’re on the LAN.
From there routing takes place.
Is this the firms first VPN deployment?
Not having a go, just need to understand the problem you’re trying to solve
While the original commenters comments are quite confusing and not at all helpful, the solution is quite simple:
Configure your VPN client to push a routing entry into your clients routing table that prioritizes the VPN as default. That way you really don’t need to care about the IP spaces of your org and the clients LAN colliding, because the only app actually using the LAN space is the VPN client. Everything else is pushed through the VPN. The only “drawback” is that your client won’t be able to access resources within it’s LAN, which from a security point of view is not even a drawback.
Some ISPs default to it yes, but that’s the problem with RFC1918 space…
Thanks for the note.
198.18 is probably the one you’re gonna have the least conflicts with (least used).
This will not work with Palo Alto Globalprotect.
You’re taking about DHCP which is fine. You can also split tunnel so clients can still access their LAN.
What question did you answer which I didn’t.
I have talked with exactly zero words about DHCP. DHCP is also absolutely irrelevant to the OPs question.
What I talked about is to specifically not split tunnel.
How does a route get pushed to a client.
Through DHCP.
You said clients can’t access their LAN. They can, split tunnel. “Client won’t be able to access resources on their LAN”
Nope, not only. DHCP can give a client a default route. You can also manually configure a default route. You can also manually edit the routing table to even set specific routes, which may be helpful if your host has multiple interfaces pointing into different networks, for example a physical NIC and a virtual NIC created by a VPN client. And you can have your VPN-Client set those routes.
Again, I am specifically talking about disabling split tunneling by having the VPN Client set the default route to point through the tunnel. Why is reading comprehension so difficult for you? Why are you having difficulties connecting the context of two sentences?