Windows VPN server can talk to VPN clients, but won't send packets from its local network to the VPN clients
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
Solution 1:
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.