Remote Access Design Guidelines – Part 5: Where to place RRAS server

Hello Customers,

In this post, I will highlight on various placement requirements related to RAS server.

5.1 NAT Routers

A VPN server machine can sit behind a NAT router as long as following requirements are met:

• For SSTP, NAT port redirection or bi-directional should be configured on NAT router – to redirect the HTTPS packets coming in from Internet side to the VPN server. This includes SSTP based HTTPS packets (TCP port 443).
• For PPTP, NAT port redirection or bi-directional should be configured on NAT router – to redirect all the PPTP packets coming in from Internet side to the VPN server. This includes PPTP tunnel control packets (TCP port number 1723) and PPTP tunnel data packets (IP Protocol type as 47 i.e. GRE).

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:

• For L2TP/IPSec or IKEv2, the NAT-T (or NAT traversal) is enabled on both ends i.e. VPN client and VPN server – which is indeed the case for Windows based VPN client and VPN Server
• For SSTP, no extra change is required as it works over HTTPS which by default is supported by all flavour of NAT router.
• For PPTP, the PPTP editor (or sometimes called as application level gateway) is enabled on NAT router.

5.2 Packet Filtering

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:

• Place a network based firewall between Internet and RRAS server. And allowing only specific ports destined to VPN server.
• Enable Windows based host firewall on the RRAS server.
• Enable stateless packet filtering on the RRAS server on the public interface.

The difference between Windows host firewall and RRAS packet filtering can be summarized in following table:

The ports that should be opened for VPN tunnels are: -

• VPN Reconnect or IKEv2: UDP Port 500 (IKE), UDP Port 4500 (NAT-T – Data) and IP Protocol 50 (ESP – Data)
• SSTP: TCP Port 443
• L2TP: UDP Port 500 (IKE), UDP Port 4500 (NAT-T – Data) and IP Protocol 50 (ESP – Data)
• PPTP: TCP Port 1723 (Control) and IP Protocol Type 47 (GRE –Data)

For further details, please refer to this blog on Firewall vs static filters and this post on port numbers.

5.3 Single NIC scenario

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.

5.4 Load Balancing and High availability

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:

5.4.1 DNS Round robin

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:

• It doesn’t take into consideration usage metrics of a given server – thereby may yield to different load on each server.
• Whenever a VPN server goes down, the DNS records in the DNS server need to be “manually” updated to reflect the change.

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.

5.4.2 Network Load Balancing

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.

5.4.3 SSL Load Balancers (only for SSTP)

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:

• SSL load balancers terminates SSL and only sends HTTP packets to VPN server – thereby removing the encryption/decryption load from the VPN server.
• SSL load balancers are stateful in nature and keep track of the HTTPS sessions passing through it. This way a VPN server going down is discovered by load balancer which then removes that VPN server from its pool.

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.

5.5 Further Readings

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

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

[This posting is provided “AS IS” with no warranties, and confers no rights.]

Comments

• Anonymous
  January 01, 2003
  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? Thank you, Dan

• Anonymous
  January 01, 2003
  Hello Customers, In last few releases, we have added plenty of “cool” features in RAS – like NAP based

• Anonymous
  January 01, 2003
  Thanks for the response Samir, and thanks, too, for these informative blog entries. Dan

• Anonymous
  March 18, 2009
  Dan Wrote: "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? Thank you, Dan" SAMIRJ wrote: 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