VPN issues when in hotels 1

[gtmoore]

I just started for a company that has their server network on 192.168.0.0 network. They can VPN fine through the ISA server. The problem is when they travel , some hotels give you a network of 192.168.0.0. So they can not synch their email and do some other work on the servers. Is there a way around this other then changing the server network because that could be a nightmare? Any input appreciated.

Greg

 

[bwilliam13]

What kind of VPN server are you using?

 

[gtmoore]

Microsoft .. Vpn to our ISA server

 

[John Lewis]

255 possible network addresses in the 192.168 RFC pool and (almost) everybody uses the same one. It's really not supposed to be that way, but the tendancy is to open the new network goodies, throw it on the net, and if it works with the defaults then let it run.

Before this goes too much farther, should note that your issue is one related to routing, not the core VPN connection. You should be able to reach resources on the VPN server without doing anything else, simply by using the VPN server tunnel address. You will not, however, be able to route to your server side network without a lot of work.

Solutions . . . well, the best long term solution would be to change your server side network address. Your present configuration will probably cause a problem somewhere else sooner or later, anyway. If your only objection to changing your network is the time and energy required to get everything working again and the VPN connection is of any importance at all, that is the way to go. I'll discuss some other options, but although they should work, they will be more work than renumbering your network.

If you do decide to renumber, try to do it right. The network address should be random within the range specified by the RFC. You should carfully select a network address without giving it any thought at all! Sounds wierd, doesn't it. The 192.168 is good, but the third octet is the problem. Best procedure for picking that number . . .

Get 255 small pieces of paper. Write a number on each, starting with 0 and moving on to 254. These represent the possible third octet of your network address. Grab the trash can and throw 0 in there. This is the default for many network gadgets, so a lot of people are using it. There are also devices that use 1 for a default, so throw that out as well. 2 - 5 go in the trash because often people with more than one net address to deal with just increment by one. 5 should get you past that. Discard 20 - 22, 48, 100 and 200, some well intentioned authors have suggested those addresses in their books in an effort to eliminate the problems you are having without really explaining the proper procedure. I'm sure there are others that fall into that catagory, but those are the ones I've run across. 127 and 254 go in the trash because there is a certain amount of network gear that doesn't deal with it well. You should now have 241 pieces of paper. Throw them in a hat, stir well and pick one. Now you have your new address. We all know that's the easiest part of the deal, but you still have to do it right.

Now, I promised some other options. They all have some problems, but here goes.

First would be to run some form of simple one - to - one NAT on the VPN server for the VPN connection. Don't know if that is really even an option with a MS box, but it can work fairly well with a Linux box running netfilter/tables. Basically, your the NAT would take your 192.168.0 addresses and convert them to 192.168.something_else for your VPN connection. Setting up proper name resolution is the hardest part of that one, agian given a Linux box in the picture.

Next option would be to modify the routing table on the client computer after the connection is made. You would need to add a host route to each of the servers that you need on your VPN server side. If you are using CMAK to make your client side VPN connection, you could use CMRoute to deal with this, otherwise you would need to write a script for the user to run after the connection is made. The latter would require that your clients are getting fixed IPs for their VPN endpoint. The problem here is that if one of your server computers has the same IP as the router, dns server, etc on the client side network you would loose connectivity to that device. In the case of the gateway on the client side having a duplicated address, you would loose connectivity altogether.

Third option would be to move all of the services that you really need to the VPN server, or proxy them there depending upon the type of service. Many MS services don't like to play with RRAS on the same box, so that creates it's own little problem. Exchange server is particuarly bad. Not fun, at the very least.

Sorry for the long winded post, perhaps got a little carried away. Hope this gives you some idea of the fun you have ahead of you.

 

[bwilliam13]

Put a static route on the VPN server that says to route 192.168.0.X traffic to inside your network only. Then, on your VPN client, check the option that says "Use default gateway on remote network". Your VPN clients won't be able to surf the network while connected to your VPN server, but they will be able to do whatever they need to do to get their email and other services off of the corporate network.

If this is not satisfactory, I would suggest the thinks mhkwood has already outlined.

I would actually renumber the corporate network on your side to a 10.x.x.x address scheme. Most small hotel and home networks will stick with the 192.168.x.x scheme. Corporate networks will go with the 10.x.x.x because there's greater expansion of the network without causing routing issues like you have with VPN setups.

 

[gtmoore]

Guys, thanks for all the input. I do agree with you that we need to change the server network addresses. I have no idea why they put the server network on the 192.168.0.x network. According to them, it would be a nightmare to change the servers IP addresses because some of their applications & services refer to IP addresses and not names. I am still trying to push the issue of changing the server network to the 172.16-31.x.x networks. I think those addresses are not as popular. I am going to try bwilliams suggestion because I think it would be the easiest and still accomplish the primary objective. I will let you guys know if this works. Again thanks for the input.

Greg

 

[John Lewis]

Using the default route won't help here.

When a VPN client is connected to hotel network on 192.168.0, the network card has a 192.168.0 address. Because there is an address on the machine within the 192.168.0 network, traffic to that network is local and therefore does not go to the default route regardless of the routing table. If it did, how would the encapsulated VPN packets reach the local router to make it to the internet and then on to the VPN server?

In theory, MS networking being what it is, you may be able to use netsh to force the netmask to 255.255.255.255 and add an implicit route to the local gateway, but I would have to imagine it would be a nightmare to get something that worked consistently over a range of configurations.

 

[gtmoore]

Point well taken. I think the solution is to tell my CIO this will not work until we change the ip addresses on the servers.