Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Friday, January 10, 2014 2:22 PM
I 've setup a Windows Server 2008 machine as a VPN(PPTP) server. The server has two network interfaces - one private (192.168.9.0/24) and the other public (Internet). I've a Windows 7 PC connected to the server on local LAN, with IP 192.168.9.3 and gateway 192.168.9.1.
Secondly, I've a router at a remote location in which I've configured it as a VPN client and setup it up to connect to the VPN server via the WAN. The router's LAN has an IP 192.168.8.1 and is connected to a Windows 7 PC with IP 192.168.8.3 and gateway 192.168.8.1. The server's VPN settings are configured to use a IP pool of 192.168.7.1-192.168.7.20. The server takes up the 192.168.7.1 on the tunnel, and the remote router gets assigned for example, 192.168.7.5.
So far everything is fine, except that in my scenario I need the Win7 PC with 192.168.9.3 IP to connect to a TCP port (e.g., FTP) on the 192.168.8.3 Win7 PC through the VPN. This is the reverse of typical VPN requirement. I'm so far able to connect to the 192.168.8.3 PC using a client running on the server itself. The server correctly routes the traffic through the VPN tunnel to the remote end. I'm also able to ping the remote VPN tunnel end, i.e., 192.168.7.5 from the server.
However, if I run the same client application on the 192.168.9.3 PC and try to connect to the 192.168.8.3 PC, I can't get through. From this PC I can't even ping the remote VPN tunnel-end (192.168.7.5).
What could be the issue, and how to fix it?
Thanks!
VK
All replies (6)
Saturday, January 11, 2014 12:11 AM ✅Answered
Why are you using a pool of addresses in a different IP subnet? This makes life difficult.
If you use on-subnet addressing, the VPN server acts as a proxy for the remote client and does proxy ARP on the LAN on its behalf (so that the remote client appears to be on the LAN).
If you use off-subnet addressing, the task of routing traffic between the subnets is up to you and is a whole new ballgame.
Even so I doubt that on subnet addressing would solve your problem. The best solution would be a site to site VPN connection, but that requires a VPN router at both sites.
Without that you will need to set up routing between the 192.168.9 an 192.168.8 subnets (and name resolution if you want to connect by name) across the VPN link. It won't happen by default.
Bill
Saturday, January 11, 2014 12:54 AM ✅Answered
To route through the tunnel, you use static routes pointing to the tunnel endpoint, not the default gateway. This ensures that the packet is properly encrypted and encapsulated before it goes to the public network.
Bill
Monday, January 13, 2014 12:02 AM ✅Answered
If only one PC is involved, you might as well put the static route on the PC. If you want to route the whole subnet you put it on the default gateway router (to bounce the traffic to where it should go).
You are really complicating things by wanting to initiate the connection at the VPN server end. The whole design of the system is based on a client-server model which assumes that connections will be initiated at the client end.
Full interaction between two sites is usually handled by a site to site connection which has a router at either end. The VPN connection is established between the two routers, not as a client-server setup.
You also have to remember that routing is a two-way process. Getting the packets from A to B is fine, but you also need a path from B to A for a connection to work.
Bill
Monday, January 13, 2014 4:51 AM ✅Answered
To summarise, the basic problem with using a client-style VPN connection is that the VPN server at the other end is only aware of that machine. Even though it is a router, it has only made a client connection and the remote VPN will only route traffic to it (a client connection only gets a host route). What you have to do is trick the VPN server into routing traffic for the subnet behind it through the tunnel as well.
To be specific rather than general, to get traffic for the whole 192.168.8.0/24 subnet to use the tunnel you would need a static route at the VPN server end to send it to the tunnel endpoint. By default the server will only send traffic for its client (the router) using a host route.
Look at the routing table on the VPN server when the connection is up and see what gateway it allocates to this host route (I would guess 192.168.7.1). Now create a static route for the whole subnet using that same gateway address and it should work.
Bill
Sunday, January 12, 2014 7:57 AM
Thanks Bill for the reply.
So you suggest that I keep the 192.168.9.3 PC on the same subnet as the VPN, i.e., something like 192.168.7.100?
I'll give this a try and post an update
Sunday, January 12, 2014 7:58 AM
Where should I add the static route? I have a route on the VPN server indicating it to route traffic intended for 192.168.8.x through 192.168.7.5 as a gateway.
On the 192.168.9.3 PC, the server (192.168.9.1) is the gateway.