Office subnet conflicts with home subnet

ciggwin

Supreme [H]ardness
Joined
May 30, 2006
Messages
4,861
Here is my problem...

UserA goes to work at home and pulls 192.168.1.9 as an IP on their home network. Then UserA connects to the work VPN which has the same subnet (I don't know much about subnetting) 192.168.1.x - specifically the mail server is 192.168.1.9. Therefore there is a conflict and I believe the cause is because the VPN uses split tunneling.

What are my options to resolve this? The problem is that Outlook is not functioning properly and they are getting autodiscover/certificate popups, ultimately not letting them connect to Exchange.

I'm going to be re-numbering (whatever you call it) the network so that I will have a 10.0.0 or something that is not going to conflict with 99% of home networks but I a.) don't know enough to do it yet and b.) am probably going to wait until we move the office in a few months

Thanks all

 
Make the home user change their home subnet.. Or help them change their home subnet. Re-IPing everything would work, but be a painful process depending on large your business is. We have that now where one of our vpn networks overlaps with a users home network. I told him I'd help him change it and he was pretty receptive to it
 
I have been reading up on this a little and it seems like re-addressing the entire network OR re-addressing the user's home network is the only way to fix this. I've done this over the phone before and it took about 3 hours. I may just go stop by the EVP's house on the way home to do it for him as he is one of the users having the issue.

Bleh.

 
If you are going to have a bunch of people vpn in the best idea is to change the ip range on your internal network. Keep it off 192.168.x.x, 192.168.1.x, 192.168.2.x, 192.168.10.x and 10.1.10.X as they are the most common used.

Any new networks I set up I usually set up in the 172 range as it seems to be used less.

Fun part on home networks is everything you don't think of while walking someone through it over the phone. Things like wifi printers for example. Another thing to consider are cable boxes. Verizon's fios for instance uses the internet router for the cables boxes onscreen guides and whatnot. They pull an ip address from the box via a special dhcp range over coax. You can change it but if an issue comes up verizon is going to reset the router to its defaults instead of messing with the changed config. This is going to be the standard practice for other isps as well.
 
If you are going to have a bunch of people vpn in the best idea is to change the ip range on your internal network. Keep it off 192.168.x.x, 192.168.1.x, 192.168.2.x, 192.168.10.x and 10.1.10.X as they are the most common used.

Any new networks I set up I usually set up in the 172 range as it seems to be used less.

Fun part on home networks is everything you don't think of while walking someone through it over the phone. Things like wifi printers for example. Another thing to consider are cable boxes. Verizon's fios for instance uses the internet router for the cables boxes onscreen guides and whatnot. They pull an ip address from the box via a special dhcp range over coax. You can change it but if an issue comes up verizon is going to reset the router to its defaults instead of messing with the changed config. This is going to be the standard practice for other isps as well.

How complicated is it to change the internal IP range? I am going to research this but didn't know if anyone had some cliffs.

 
How complicated is it to change the internal IP range? I am going to research this but didn't know if anyone had some cliffs.


Depends on how many servers and whatnot are on the network.

Pretty much change router, change ips on server, change dns on domain servers, change dhcp range, restart all clients and let them get a new address. Also need to change the ip of anything that has a static ip address like printers, some workstations, etc. How many computers and what not are internal?

Mind you for something like outlook if you are using exchange you could always just configure rpc over https and let outlook connect from outside the network. Not much harder to setup then setting up webmail to work outside of the network.
 
Depends on how many servers and whatnot are on the network.

Pretty much change router, change ips on server, change dns on domain servers, change dhcp range, restart all clients and let them get a new address. Also need to change the ip of anything that has a static ip address like printers, some workstations, etc. How many computers and what not are internal?

Mind you for something like outlook if you are using exchange you could always just configure rpc over https and let outlook connect from outside the network. Not much harder to setup then setting up webmail to work outside of the network.

50 computers, 5 servers, 2 printers... so 57 devices. I think the hardest part would be going around to all of our WAPs and updating those (I believe they have static addresses). They are all individually configured.

 
50 computers, 5 servers, 2 printers... so 57 devices. I think the hardest part would be going around to all of our WAPs and updating those (I believe they have static addresses). They are all individually configured.


Are all of the computers running dhcp? What besides outlook do people on the outside need to access?
 
Are all of the computers running dhcp? What besides outlook do people on the outside need to access?

Yes all DHCP. Access just some shared drives (and obviously Exchange) via VPN. We are pretty basic and a lot of our apps are online.
 
Yes all DHCP. Access just some shared drives (and obviously Exchange) via VPN. We are pretty basic and a lot of our apps are online.

That makes it easier. If it wasn't for the sharred drives I'd say just use rpc over https for outlook outside the office. With the sharred drives you pretty much need to do something else. You could always setup the vpn on a different subnet and give those servers a second set of ips but I'd personally switch the internal range or have to switch the range on your users home ranges.
 
Yeah, this is an issue. This is why when we setup a small network we'll just choose a random number like 192.168.78.x or whatever. Even if they aren't using a VPN currently at some point in the future they may and this avoids most issues.
 
Change the office subnet. Period.

if a user has a problem with their home internet service, their ISP may have them reset their router which defaults back to the 192.168.0.x or 192.168.1.x subnet.

If a user changes ISPs, the ISP may replace their router which will again default back to the aforementioned subnets.

If the user's router fails and gets replaced, a new factory default router will be on the aforementioned default subnets.

Multiply the above by "X" number of VPN users and you'll quickly realize readdressing your office network will result less problems in the long term.
 
That makes it easier. If it wasn't for the sharred drives I'd say just use rpc over https for outlook outside the office. With the sharred drives you pretty much need to do something else. You could always setup the vpn on a different subnet and give those servers a second set of ips but I'd personally switch the internal range or have to switch the range on your users home ranges.

But even if you change the subnet of addresses that the VPN users pull, the issue still exists in that my mail server is 192.168.1.9 and their home network is on the same subnet scheme... right?

 
But even if you change the subnet of addresses that the VPN users pull, the issue still exists in that my mail server is 192.168.1.9 and their home network is on the same subnet scheme... right?


You can setup multiple IP's so it also responds to a second ip address. It really isn't the best way to do it though. Changing the internal ip range is the best bet to limit problems in the future.
 
Can you folks help me with my checklist for changing the internal subnet?

  1. change DHCP to give out 172.16.1.x
  2. change server static IPs to match range
  3. change default gateway to 172.16.1.1
  4. change SonicWALL address objects for mail
  5. change SonicWALL address objects for Cisco VPN concentrator
  6. change Cisco VPN concentrator static IP
  7. change printer static IP addresses
  8. change DNS entries to show new IP addresses

 
Another way is to give out a different set of IP's when connecting by VPN. We have a completely separate /24 dedicated for our Remote VPN users.

From the checklist it seems like you have a sonicwall and a cisco VPN concentrator.

Do you have a L3 Switch inside the network or is the sonicwall the only routing device?

If the sonicwall is the only routing device, just bring up another interface, stick the vpn concentrator on that segment and start handing our a different range of IP.

This way you can leave your office network alone and it doesn't matter what network they use home, as long as it isn't the same range as your VPN one. 172.16.x.x is a good range and we haven't seen any problems with those with our vpn users.
 
Can you folks help me with my checklist for changing the internal subnet?

  1. change DHCP to give out 172.16.1.x
  2. change server static IPs to match range
  3. change default gateway to 172.16.1.1
  4. change SonicWALL address objects for mail
  5. change SonicWALL address objects for Cisco VPN concentrator
  6. change Cisco VPN concentrator static IP
  7. change printer static IP addresses
  8. change DNS entries to show new IP addresses


Flush DNS on the machines as well.
 
Another way is to give out a different set of IP's when connecting by VPN. We have a completely separate /24 dedicated for our Remote VPN users.
Problem is, user needs access to "company" subnet locally to even be able to use internet (and then vpn). But this along with NAT might work (depending on services used).

In the long term, renumbering company net is probably a better solution (less error-prone).
 
We switched all of our laptop users over to Win7 and now use Direct Access exclusively for their remote access needs. Our other users work from home with remote desktop, which is tunneled over https through our terminal services gateway.
 
Last edited:
Back
Top