VPN networking issue

Posted on

VPN networking issue – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.

But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about windows, networking, vpn, routing, .

I have 2 servers hosted in the cloud. One an application server, one a VPN server, both running Win2008.

Both have a local IP address assigned by DHCP in different network subnets, 10.227.55.0 (VPN) and 10.231.5.0 (App Server). These servers can ping each other.

My VPN client connects in to the VPN server (using a L2TP connection on a Win7 client). It is assigned an IP Address from the VPN server’s static pool (the VPN server takes 192.168.100.1, the client is given 192.168.100.2). The client can ping both the 192.168.100.1 address of the VPN server, and its ‘local’ IP address (10.227.55.X).

What the client can’t do is ping the App Server. How can I configure routing so that my client can access the App Server, without hard-coding any of the DHCP IP addresses anywhere?

thanks

Duncan

Solution :

Without knowing how the subnets are setup on your cloud machines…Your VPN server is accessible from your remote client because its routing table is “aware” of both networks (10.x.x.x and 192.168.100.x). The application server likely doesn’t know anything about the 192.168.100.x network so when it receives traffic with a source address from 192.168.100.x, it won’t know what to do with it in response and will drop it because its routing table doesn’t have what it needs. Try adding a static route to the application server for the 192.168.100.0/24 network to route to 10.227.55.y (your app servers IP address). Don’t forget to make it a persisent route so it survives reboots. It will look something like this:

route -p add 192.168.100.0 mask 255.255.255.0 10.227.55.y 

This entry is assuming I’ve got your network subnets right, but you should be able to replace it as needed to make it work. You can also check the routing table of each server by doing a ‘route print’ command. Hope this helps.

Leave a Reply

Your email address will not be published. Required fields are marked *