OpenVPN IP conflict (same subnet)
-
So I have a number of clients that are connecting to my OpenVPN server. The issue is that a few of them are on the same subnet (192.168.1.1/24) as my server. Is there a way to make it so that when client A connects, I can put them on a different subnet so that there's no conflict between my LAN and theirs?
-
The "easy" method is to always use "random" private address space for VPN tunnels and LANs that need to be reached from clients at the other end of a road-warrior VPN. Pick from bits of 10.0.0.0/8 and/or 172.16.0.0/12
-
~~Why are your clients being assigned addresses from your LAN?
Do you have the same subnet assigned as your tunnel network as your LAN?
Don't do that.~~
Oh. I see now. Yeah. It's up to those who know to protect those who don't by using random RFC1918 IP schemes.
If you have a specific site-to-site that can't renumber, you have to NAT them. It might be easier to have them renumber.
-
The "easy" method is to always use "random" private address space for VPN tunnels and LANs
$ perl randomlan.pl
10.113.170.0
172.28.142.0
192.168.222.0 -
I use my random fingers to generate those…
-
The sites that are not renumbering are the local Cafe… wherever the Road Warrior happens to be sitting sipping coffee at the time.
-
"I can put them on a different subnet so that there's no conflict between my LAN and theirs?"
While your tunnel network for sure should be different than their local network, if your local pfsense 192.168.1.0/24 conflicts with their local network. Say starbucks is using 192.168.1.0/24 as well - this only matters if trying to access resources on your network. If just using the tunnel for internet does not matter. As long as you tunnel network doesn't match up - which it shouldn't since it should be something really small mask /29 for example
But how you work out the issue is use something random, say 172.20.122.0/24 or 10.192.14.0/24 for your local network. Where you still have a problem is if someone used 10/8 for their network.. Which I have seen ;) Which is why I would prob suggest something odd for 3rd octet in 192.168 since that is always /24 or smaller gives you odds of 1 out of 254 possible octets. While 172 only gives you 16 different octets they might match on..
-
The clients can access the web without issue, but the do need access to a local asset. I'm also giving them access to the gateway for DNS so that they can use aliases instead of IPs.
So it looks like the simplest path is to re-IP my local LAN to something "random" (the third octet). What if I'm unable to do that and can't re-IP the local LAN. Is there a way to avoid conflicts using another method (NAT?)? If so, how would I go about doing that? My tunnel is 10.10.0.0/24, so I'm not really worried for conflicts on that IP (hopefully)
-
Look up 1:1 NAT for an entire network. You have to NAT both sides.
Never use 10.0.0.0/anything, 192.168.0.0/24 or 192.168.1.0/24
Renumbering your end is easier, more straightforward, and easier to debug months down the road.
-
But how you work out the issue is use something random, say 172.20.122.0/24 or 10.192.14.0/24 for your local network. Where you still have a problem is if someone used 10/8 for their network.. Which I have seen ;) Which is why I would prob suggest something odd for 3rd octet in 192.168 since that is always /24 or smaller gives you odds of 1 out of 254 possible octets. While 172 only gives you 16 different octets they might match on..
Very few people use 172.16/12. Those that do have a pretty decent chance of having a clue and hopefully dole out /24s which kind of gives you a 1 in 4096 chance at a collision (12 bits). Probably quite a bit less in reality but probably greater than 1:253 (192.168.0 and 1 are useless.) But as far as odds go you have to add the countless 10/8-24 and 192.168.0/16 networks you can't collide with so I feel it makes it a better choice.
-
Is there an easy/quick way to re-IP my LAN (everything is on a DHCP/DNS), or do I need to go through everything manually (DHCP, DNS, firewall rules, NAT, etc.)?
-
All you should have to do is change the interface IP, change the DHCP server, then have everything on the interface get new DHCP (reboot, unplug from network for a few secs/plug back in, disable/enable switch ports, release/renew, whatever).
If you have DNS entries for local IPs they'll also have to be adjusted.
If you are using LAN net in your rules and have automatic outbound NAT, that should catch about everything. Only you know the rules you have. Anything that refers to the old network will have to be changed.
-
Derelict is right…
It also try that someone out there MIGHT happen to have an IP that will conflict with your setup after you make these changes...
But thats just one guy... Better to have 1 random guy be screwed than lots and lots of people.
You are definitely being pointed in the right direction. -
Do a quick search of your config file for "192.168.1" - that will quickly show where are the other references to things in 192.168.1.0/24
And of course you have to change any clients with hard-coded IP addresses (maybe some Windows servers, a managed switch, an AP or 2, a print server lying around your LAN…)
