Windows VPN server can talk to VPN clients, but won’t send packets from its local network to the VPN clients

routingrrasvpnwindows-server-2012

I want to configure Windows Server 2012, and its Windows 7 and Windows 8 VPN clients, with an SSTP VPN that uses split tunneling and off-subnet addressing, but I'm running into a problem: the RRAS server will not send packets to VPN clients from any machine other than itself.

My VPN server is running on Amazon's "Virtual Private Cloud", so it has only one NIC with an IP address on a private, RFC1918 network shared with all my other Amazon VPC servers, and a public IP which forwards all traffic to that private address via NAT (Amazon calls this "Elastic IP").

I've installed RRAS and set up a VPN. The private subnet on Amazon is 172.16.0.0/17 (this is what I'm calling the "Amazon LAN"), but I want all the VPN clients to use the range 10.128.0.0/20 (what I'm calling the "VPN LAN").

In my Amazon control panel, I've done the following:

  • Disabled the source/destination check for the VPN server
  • Added an entry into the route tables for the 10.128.0.0/20 pool that points to the network interface of the VPN server.

Inside the Routing and Remote Access MMC, inside the properties menu for the server name, I've done the following:

  • General tab -> IPv4 Router (checked), enabled for LAN and demand-dial routing
  • General tab -> IPv4 Remote Access Server (checked)
  • IPv4 tab -> Enable IPv4 Forwarding (checked)
  • IPv4 tab -> Static Address Pool, and specify 10.128.0.1-10.128.15.154

On my client and all my servers, I've made sure that ICMP is explicitly allowed in the firewall, or the firewall is disabled entirely (not the permanent plan, of course).

On the client, to enable split tunneling, I've gone to the properties for the VPN connection -> Networking -> IPv4 -> Propeties -> Advanced -> IP Settings tab, and unchecked "Use default gateway on remote network", and checked "Disable class based route addition".

At this point, my clients can connect using the Windows 7/8 VPN client. They are assigned an IP from the 10.128.0.0/20 pool, but since they aren't automatically setting any routes, they can't talk to the remote network. I can set routes to the remote network, and to the VPN network, like this (on the client):

route add 172.16.0.0/17 <VPN IP ADDRESS> 
route add 10.128.0.0/20 <VPN IP ADDRESS> 

Now the client can ping the VPN LAN address of the VPN server (10.128.0.1), and also its Amazon LAN address (172.16.1.32). It runs into a problem, though, when trying to talk to other machines on the Amazon LAN: pings don't receive replies.

So, for example, if the client tries to ping a system that I know is up and responds to pings like 172.16.0.113, it won't see those replies (it says "Request timed out"). Wireshark on the VPN server confirms that it sees the ping from the client, and it even sees a reply sent from 172.16.0.113, but that reply apparently never makes it back to the client.

Furthermore, if I ping the client's VPN LAN address from 172.16.0.113, Wireshark on the VPN server sees the ping, but doesn't see a reply.

So, to recap:

  • The VPN server can ping other machines on the Amazon LAN (172.16.0.0/17) and receive replies, and other machines on that network can do the same to it.
  • A VPN client can ping the server's Amazon LAN address and receive replies, after the clients adds the proper route as described previously.
  • A VPN client can ping the server's VPN LAN address of 10.128.0.1, and the VPN server can ping the client's VPN LAN address in the 10.128.0.0/20 range, after the client adds the route proper route as described previously.
  • A VPN client can send pings to a machine on the Amazon LAN, but when those machines send replies, they stop at the VPN server – they don't get forwarded on to the client, resulting in "Request timed out" messages on the client. Conversely, when a machine on the Amazon LAN tries to ping the client's 10.128.0.0/20 VPN LAN address, the VPN server sees the ping, but the client never does and therefore doesn't generate a reply.

Why isn't the VPN server sending packets from the Amazon LAN down to its clients on the VPN LAN? It can definitely talk to the clients on the VPN LAN, and routing is enabled, and it's willing to route the packets from VPN LAN -> Amazon LAN, but not the reverse. What am I missing here?

Routes

Here are the routing tables from a VPN client. The client is a VirtualBox VM running Windows 8. It's vbox adapter's IP address is 10.0.2.15 on a /24. This client is behind NAT (actually, it's behind double-NAT, because the vbox adapter is NAT'd to my local network, which is NAT'd to the Internet). This route table is from after manually adding the routes to 10.128.0.0/20 and 172.16.0.0/17.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         10.0.2.2        10.0.2.15     10
         10.0.2.0    255.255.255.0         On-link         10.0.2.15    266
        10.0.2.15  255.255.255.255         On-link         10.0.2.15    266
       10.0.2.255  255.255.255.255         On-link         10.0.2.15    266
       10.128.0.0    255.255.240.0         On-link        10.128.0.3     15
       10.128.0.3  255.255.255.255         On-link        10.128.0.3    266
    10.128.15.255  255.255.255.255         On-link        10.128.0.3    266
    54.213.67.179  255.255.255.255         10.0.2.2        10.0.2.15     11
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
       172.16.0.0    255.255.128.0         On-link        10.128.0.3     15
   172.16.127.255  255.255.255.255         On-link        10.128.0.3    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link         10.0.2.15    266
        224.0.0.0        240.0.0.0         On-link        10.128.0.3    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link         10.0.2.15    266
  255.255.255.255  255.255.255.255         On-link        10.128.0.3    266
===========================================================================
Persistent Routes:
  None

Here are the routing tables from the RRAS server, which is running Windows Server 2012. This server is also behind NAT, as discussed above. It only has one NIC. Its private IP address is 172.16.1.32, on a /23 (that is itself part of a larger /17 network; I believe it's fair to ignore the parts of the /17 outside of the /23, since other machines on the /23 can't reach or be reached by VPN clients either).

The VPN virtual adapter has its own address, 10.128.0.1, which is assigned automatically the first time a client connects. The routes for 10.128.0.1 (to itself) and 10.128.0.2 (to its only client) that you see are also added automatically at that time. No routes are added to the VPN server manually.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       172.16.0.1      172.16.1.32     10
       10.128.0.1  255.255.255.255         On-link        10.128.0.1    286
       10.128.0.2  255.255.255.255       10.128.0.2       10.128.0.1     31
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  169.254.169.250  255.255.255.255       172.16.0.1      172.16.1.32     10
  169.254.169.251  255.255.255.255       172.16.0.1      172.16.1.32     10
  169.254.169.254  255.255.255.255       172.16.0.1      172.16.1.32     10
       172.16.0.0    255.255.254.0         On-link       172.16.1.32     11
      172.16.1.32  255.255.255.255         On-link       172.16.1.32    266
     172.16.1.255  255.255.255.255         On-link       172.16.1.32    266
       172.16.2.0    255.255.254.0      172.168.0.1      172.16.1.32     11
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       172.16.1.32    266
        224.0.0.0        240.0.0.0         On-link        10.128.0.1    286
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       172.16.1.32    266
  255.255.255.255  255.255.255.255         On-link        10.128.0.1    286
===========================================================================
Persistent Routes:
  None

Here are the routing tables for another machine on the server's private network, also running Server 2012. It has one NIC, which has a private IP address of 172.16.1.177 – which means it's on the same /23 that the VPN server is. (Note that the route to the 10.128.0.0/20 is set on the gateway, which is controlled by Amazon, so you won't see it here. I have added the correct route to Amazon, evidenced by the fact that Wireshark on the VPN server sees the packets.)

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       172.16.0.1     172.16.1.177     10
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  169.254.169.250  255.255.255.255       172.16.0.1     172.16.1.177     10
  169.254.169.251  255.255.255.255       172.16.0.1     172.16.1.177     10
  169.254.169.254  255.255.255.255       172.16.0.1     172.16.1.177     10
       172.16.0.0    255.255.254.0         On-link      172.16.1.177    266
     172.16.1.177  255.255.255.255         On-link      172.16.1.177    266
     172.16.1.255  255.255.255.255         On-link      172.16.1.177    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link      172.16.1.177    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link      172.16.1.177    266
===========================================================================
Persistent Routes:
  None

Here are the routes in the Amazon console. I do think these are correct – the traffic is making it back to the VPN server, after all, only to disappear inside of it – but in case someone wants to see them, here they are. (Amazon does things a little weird. eni-2f3e8244 / i-77e26440 refers to the NIC on the VPN server, and igw-d4bc27bc refers to the Amazon-controlled Internet NAT/gateway that all of my instances use to talk to the Internet.)

10.128.0.0/20   eni-2f3e8244 / i-77e26440   
172.16.0.0/17   local   
0.0.0.0/0       igw-d4bc27bc

Best Answer

What if you add a static route on your servers telling them that in order to reach 10.128.0.0/20 they have to go through the VPN's server LAN address?

route add 10.128.0.0 mask 255.255.240.0 a.b.c.d

Substitute a.b.c.d with the VPN server's LAN address.

This will, at least, rule out problems with amazon's routing.

Related Topic