1

I set up a VPN tunnel to my web server targetting its FQDN: (e.g. my.server.com) using the built-in Windows 7 VPN feature and the built-in Windows 8 Routing and Remote Access (RRAS) VPN feature.

How do I ensure that all traffic targetting the FQDN "my.server.com" is routed through the VPN tunnel? Specifically, if I typed \\my.server.com\sharedfolder into the Explorer address bar or map a shared drive in explorer to such a path, I want the traffic to go through the VPN associated with my.server.com.

Basically, I want Windows to be smart enough to route traffic to "my.server.com" over the encrypted VPN when the VPN to "my.server.com" is connected, and to route it normally when it's not connected. Is that too much to ask?

It seems to me that once connected, the VPN gets a local IP address like 192.168.1.101 (which I've assigned statically on the server in the dial-in tab of my user account properties), and targetting that address does route the traffic over the VPN. It seems that traffic targetting "my.server.com" is never routed over the VPN and is treated separately from the VPN's IP address, and I have to use that VPN IP address to route things over the VPN. The only benefit to that is the firewall can be configured so that file-sharing traffic can originate only from that IP address.

There are two problems with that setup:

  1. Traffic targetting "my.server.com" is not automatically routed over the VPN, which is insecure and confusing because the VPN is active. It's non-intuitive.
  2. Windows explorer tends to let drive connections time out when using a local subnet address like \\192.168.1.101\sharedfolder and Explorer freezes for a good 30 seconds when I try to access the drive again. It's really annoying, and the problem does NOT occur when the drive is mapped using the FQDN like \\my.server.com\sharedfolder... but then it's not routed over the VPN!

How can I solve this problem?

Update: I also notice the following when I have 2 VPN's connected, one with static IP 192.168.1.101 and the other with 192.168.1.102. With both VPNs established and both set to NOT use the default gateway on the VPN, and both VPNs showing those two independent IP addresses in their connection status, Explorer gets confused, cannot connect to the 2nd one, and then if I open a new window and try to go to the 2nd address, it seems to equate it with the first one and from then on both addresses (101 and 102) access the same folder on one server over the first VPN. It makes no sense.

Improve this question
10
  • This is standard VPN stuff. Network routing is always performed on an IP basis, not by domain name. So - just ensure that your VPN client is adding a route for the desired subnet, with the next hop pointing through the VPN tunnel and you should be all set.
    – EEAA
    Commented Mar 24, 2014 at 22:27
  • I need more low-level information. At some point a VPN adapter or driver must process the traffic for encyrption and then route it to the VPN server's IP address on a specific port. What I don't understand is why Windows gives two different IP addresses to two different VPNs, but only routes traffic to one VPN reguardless of which of the two IP addresses I use. Is it some kind of bug? Then there is the problem of it treating the mapped folder connection differently depending on whether a domain name or IP address is used.
    – Triynko
    Commented Mar 24, 2014 at 22:50
  • My VPN client is Windows 7; it's built-in.
    – Triynko
    Commented Mar 24, 2014 at 22:54
  • This is a routing issue. You need to make sure you have a route for each desired subnet, pointing through the desired VPN.
    – EEAA
    Commented Mar 24, 2014 at 22:56
  • Suppose I have to set up the routes manually. The problem is that Windows is assigning the same Server IPv4 address to both VPN connections, so I cannot target one VPN separate from the other. I'm really looking for someone who knows how to set up 2 VPNs in Windows 7 and how to route traffic to one or the other (e.g. where to look in the VPN's status window for the correct IP address to use).
    – Triynko
    Commented Mar 24, 2014 at 22:58

1 Answer 1

Reset to default
1

I figured this out on my own.

In order to route based on the FQDN, one may need to run a DNS server on the client capable of detecting when a VPN is active on that FQDN's WAN address. When it detects an active VPN connection, it could resolve the FQDN to the VPN tunnel address instead, so that applications (web browsers, etc.) would receive the VPN tunnel address instead of the WAN address of the server. Since that would pose issues for SSL certificates that show which IP addresses are valid, one would really need a VPN-aware network driver capable of automatically and transparently tunneling data from applications over the VPN tunnel. It could be done, but I don't know if such intelligent network drivers exist. According to this response to a bad answer, you CAN ROUTE BASED ON FQDN with the appropriate configuration as I suspected:

As for the issue of duplicate Server IPv4 addresses being assigned to different VPN servers in a Windows 7 client, this appears to be by design. In Windows Server 2008/2012 Routing and Remote Access Services (RRAS), the server utilizes an IPv4 router which can be configured to use a static address pool like so. This static pool will determine the Server IPv4 address on the client. Here I've set my second server to use 192.168.2.0/24 as its subnet, so it will receive a server IP of 192.168.2.1 on the Windows 7 client.

RRAS IP Router

My user account on each VPN server is assigned a static IP address in the Dial-In tab of the user properties under computer management. This will become the client's IPv4 address on the VPN.

enter image description here

Finally, to ensure that file sharing traffic must originate from the server's VPN subnet only, the appropriate protocols/ports in the firewall can have their remote IP restricted to to the assigned subnet:

enter image description here

Now, on the client, I can connect to file shares over the internet through this VPN which requires no 3rd party software at all. I simply map a network drive to each of the server's VPN addresses (e.g. \\192.168.1.1\sharedfolder and \\192.168.2.1\sharedfolder\).

Unfortunately, we cannot use the FQDN such as \\my.server.com\sharedfolder\ because Windows is not smart enough to realize that having a VPN connected to that IP address implies all traffic on all ports to that address except the encrypted VPN packets themselves should be be routed through the VPN IP. A side of effect of not being able to use the FQDN for the file sharing path is that windows may not keep the connection alive and will assume that it can be reestablished quickly as a local address, when in reality it will idle out after a minute and then take 30 seconds to reestablish a connection to the shared folder. This can be resolved by setting a higher idle timeout in the registry. The default idle timeout for a network share defaults to 600 seconds (10 minutes). To keep the connection alive longer, add a DWORD registry value named "KeepConn" to the registry key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters", and give it a higher value (in seconds) such as 3600, which would be an hour. According to the link:

Increase the value of this entry if your application closes and opens Universal Naming Convention (UNC) files on a server less frequently than every 10 minutes. This decreases the number of reconnections to a server.

UPDATE: I forgot to mention that although file sharing over VPN using purely built-in Windows 7 and Windows Server 2012 features, there is an extra step necessary for Windows Server 2008 because of some bug/feature where traffic on the SMB ports appear to be blocked on the default network adapter independently of the firewall. You must install the microsoft loopback adapter, which will then function identically to the default interface aside from allowing SMB traffic, so once you get it installed it should look like this. Then instead of connecting to the share on 192.168.1.1 (the Server's VPN address), you connect to 192.168.1.2, which is the loopback adapters address:

Loopback Adapter Workaround

Instructions on how to install the loopback adapter can be found here: http://blogs.msdn.com/b/virtual_pc_guy/archive/2005/10/04/477195.aspx

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .