In this post, I will highlight on various placement requirements related to RAS server.
A VPN server machine can sit behind a NAT router as long as following requirements are met:
L2TP/IPSec or IKEv2 based VPN server can sit behind NAT router – though it is NOT RECOMMENDED – as pointed by this KB article 885348. In case (like for test lab), you need to do this, please follow this configuration: NAT port redirection or bi-directional should be configured on NAT router – to redirect the IPSec packets coming in from Internet side to the VPN server. This includes IKE packets (UDP port 500) and IPSec ESP packets (UDP port 4500).
Note: For L2TP/IPSec, IKEv2 and SSTP scenario requires VPN server configured with machine certificate, care must be taken to ensure it is provisioned with appropriate subject name i.e. subject name in the machine certificate on VPN server should match the <hostname OR IP address> configured as the VPN destination on the VPN client. This name or IP address in this scenario maps to the NAT router’s public interface.
On a similar note, a VPN client machine located behind a NAT router will be able to successfully establish a VPN connection as long as following requirements are met:
A VPN server usually resides on the edge of the corporate network facing Internet and as it’s a boundary server, you should only open IP packets meant for VPN tunnel and drop the rest. This can be done by doing packet filtering in one of the following ways:
The difference between Windows host firewall and RRAS packet filtering can be summarized in following table:
RRAS Packet Filter
Type of Filtering
Applications which dynamically opens ports like RPC – requires stateful packet filtering
All IP packets destined to or originated from the machine
Can be applied on a per-interface basis – like specific LAN interface (e.g. Internet interface), particular VPN client sub-interface
RRAS packet filtering is used during NAP enforcement to restrict unhealthy client to a specific quarantine zone
Can co-exist with same machine working as NAT router
Cannot co-exist with same machine working as NAT router
NAT requires stateful packet filtering
The ports that should be opened for VPN tunnels are: -
For further details, please refer to this blog on Firewall vs static filters and this post on port numbers.
Usually VPN server has minimum two NICs – one towards public side (Internet side) through which client connects and other towards private side (Intranet side) connected to rest of intranet.
However RRAS based VPN server can also be deployed in single NIC scenario – specifically in small-medium businesses. In this scenario, RRAS server sits behind a NAT router and has only single NIC. This NIC is used as both public as well as private interface. Or in other words, the VPN tunnel packets come in from VPN client side via this network interface card, encapsulation is removed and then sent back on the same interface to rest of the intranet machines on the LAN. And on reverse side the packet goes back via RRAS server to the VPN client.
The advantage in this scenario compared to multiple NIC case is not by saving the cost of NIC, but on having single IP subnet behind your NAT router. This single IP subnet will be used by your LAN machines (say file server) as well as RRAS server and its connected remote access clients. . The advantage in this scenario is as RRAS server supports proxy ARP functionality, LAN clients automatically detects they need to send packets via RRAS server when trying to send packets to VPN clients – without any extra IP routes. And LAN clients or remote access clients can access Internet via your existing NAT router – thereby simplifying the deployment.
With increased number of mobile users and telecommuters, 24x7 remote access service has becomes life-line to organizations and this mandates a need for high availability VPN server solution. Windows based RRAS server supports high availability using multiple options:
DNS Round Robin mechanism on DNS server enables – multiple servers to be registered with the same hostname but having different IP addresses. This way you can deploy a pool of VPN servers at the edge of your network with same server name (e.g. myvpnserver.contoso.com) which can be configured as destination VPN Server in the VPN client configuration. Whenever a VPN client tries to establish the VPN tunnel, it does a name look-up and gets the IP address list from the DNS server. And client picks the first one and establishes the VPN tunnel. The DNS server sends this list differently on each DNS query in a round-robin manner – thereby load balancing each VPN connection to a different server.
This mechanism works for all VPN tunnels and requires no changes on VPN server.
However, this mechanism has some limitations:
Note: For the VPN tunnels that requires machine certificate to be installed on the VPN server i.e. L2TP/IPSec, SSTP, IKEv2 – the subject name of the machine certificate MUST match the name given in DNS server (e.g. myvpnserver.contoso.com) and not the real machine name of the VPN Server. This is because the VPN client does the subject name validation of the machine certificate sent by VPN server against the name with which it connects – and this validation will fail otherwise.
Network load balancing service (NLBS) inside Windows server is the implementation of stateless load balancing to provide high availability and scalability to different server roles. One advantage of using NLBS is that all the servers in a cluster monitor each other with a heartbeat signal, so there is no single point of failure.
For further details, refer to this article.
SSTP based VPN tunnel uses standard HTTPS protocol and hence traditional SSL load balancers (e.g. F5 BIGIP) can be used to terminate HTTPS connections coming from SSTP configured VPN clients and load balance it by sending each VPN connection to different RRAS based VPN servers.
Advantage of this approach:
Note: This scenario requires RRAS server to be configured to accept HTTP connections listening on TCP port 80. The machine certificate required for SSTP connections is installed on SSL load balancer. And its certificate hash (or thumbprint) of this machine certificate needs to be configured on RRAS server for SSTP connections to succeed (this is an additional security cover). For further details, please follow this article.
Here are the references to other relevant posts
Remote Access Design Guidelines – Part 1: Overview
Remote Access Design Guidelines – Part 2: VPN Client Software Selection
Remote Access Design Guidelines – Part 3: Tunnel Selection, Authentication, Authorization and Accounting
Remote Access Design Guidelines – Part 4: IP Routing and DNS
Remote Access Deployment – Part 1: Configuring Remote Access Clients
Remote Access Deployment – Part 2: Configuring RRAS as a VPN server
Remote Access Deployment – Part 3: Configuring RADIUS Server for remote access
Senior Program Manager
[This posting is provided “AS IS” with no warranties, and confers no rights.]
Hello Customers, In last few releases, we have added plenty of “cool” features in RAS – like NAP based
In section 5.1 above, you state that an L2TP/IPsec VPN server may be placed behind a NAT firewall/router that is performing port forwarding to 500/udp and 4500/udp. Does the guidance in KB article 885348, "IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators", still apply?
Are there version restrictions to the guidance above? For example, only Windows Server 2008 may be used in this configuration? Or, all VPN clients must be running Vista?
"In section 5.1 above, you state that an L2TP/IPsec VPN server may be placed behind a NAT firewall/router that is performing port forwarding to 500/udp and 4500/udp. Does the guidance in KB article 885348, "IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators", still apply?
You are right Dan. This scenario is not recommended and can lead to misrouting of IPSec packets in some specific cases (like client1, client2 and VPN server are all behind NAT-T. Client1 establishes IPSec based VPN connection to VPN Server. And client2 establishes direct IPSec connection (transport mode) to client1.
I will fix my blog. No changes have been done on this front in latest OS. Thanks for pointing that out
Thanks for the response Samir, and thanks, too, for these informative blog entries.