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.

Triynko
  • 3,418
  • 6
  • 31
  • 30
  • 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 Mar 24 '14 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 Mar 24 '14 at 22:50
  • My VPN client is Windows 7; it's built-in. – Triynko Mar 24 '14 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 Mar 24 '14 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 Mar 24 '14 at 22:58
  • What VPN server are you using? – EEAA Mar 24 '14 at 23:03
  • Windows Server 2008 R2 and Windows Server 2012, the built-in Routing and Remote Access VPN; they are virtually identical, and I've been using both of them for a while now. There is no third-party VPN software involved. – Triynko Mar 24 '14 at 23:04
  • When I click the network icon in the taskbar, and view the status of each VPN connection on the client they show independent "Client IPv4 address" (192.168.1.101 and 192.168.1.102), which are assigned statically to my user account on each respective server under the dial-in tab of the user account settings in computer management). The destination addresses show the two independent WAN addresses of the servers. But the "Server IPv4" addresses are both 192.168.1.1. So there's no way for me to target one or the other, and somehow the 101 and 102 addresses end up pointing to the same server. – Triynko Mar 24 '14 at 23:07
  • I also find that if I disconnect the two VPNs and connect only 1, when I try to connect to 192.168.1.1 again, explorer times out. If I run diagnostics on it, it says "file and print sharing resource (192.168.1.1) is online but itsn't responding to connection attempts). Originally I was getting that when I had to firewall restricted to the local subnet, but that's all resolved. This issues seems to stem from windows not keeping track of stuff right and leaving connections open and caching paths and rendering them invalid once you start connecting and disconnecting to different networks. – Triynko Mar 24 '14 at 23:20
  • I figured it out. I had to assign different subnets in the IPv4 routing services of the server in order to ensure the servers got different addresses. My first server allocates addresses in the subnet 192.168.1/24 and the other one allocates addresses in the subnet 192.168.2/24, which results in them getting different server IPv4 addresses (e.g. 192.168.1.1 and 192.168.2.1). I can now address them independently, the firewall is set up to allow sharing protocols only from those IP addresses, and everything is working fine. No 3rd party software required. – Triynko Mar 25 '14 at 16:33

1 Answers1

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

Community
  • 1
Triynko
  • 3,418
  • 6
  • 31
  • 30