Always On VPN and RRAS with Single NIC

Always On VPN and RRAS with Single NICI’m commonly asked “can Windows Server with Routing and Remote Access Service (RRAS) be configured with a single network interface?” This is likely because the official Microsoft documentation references only a multihomed dual NIC configuration, leading many to believe it is a strict requirement.

Single NIC

Deploying Windows Server RRAS with a single network interface is indeed supported and works without issue. There are no functional limitations imposed by using a single network interface. All features are fully supported in this scenario. The choice to use one or two network interfaces is purely a design choice, driven by several factors such as current network configuration and security requirements.

Dual NIC

Although a single NIC configuration is fully supported, there are some important advantages associated with mulithome dual NIC deployments. The following should be considered when deciding between single NIC and dual NIC VPN configurations.

Traffic Segmentation

Having separate internal and external network connections provides logical and physical separation of trusted and untrusted network traffic. Terminating connections from Always On VPN clients on the Internet in an isolated perimeter or DMZ network yields positive security benefits.

Firewall Configuration

Using two network interfaces allows for a more restrictive Windows Firewall policy to be applied to the external interface. This reduces the exposure of running services on the RRAS server to untrusted networks. This is especially critical if the VPN server is Windows Server RRAS and it is joined to a domain.

Network Performance

For very busy RRAS servers, having two network interfaces can improve network performance. With two network interfaces, network traffic is distributed between two network adapters, reducing utilization on each interface.

Dual NIC Best Practices

When deploying an RRAS server with dual NICs, the following recommendations for network interface configuration should be followed.

IP Addressing

Each network interface must be assigned an IP address from a unique subnet. Having both NICs on the same subnet is not supported.

Default Gateway

The default gateway should be configured on the external facing network interface only. The internal interface should not be configured with a gateway. Rather, static routes to any remote internal networks should be configured.

To add a static route on a Windows Server, open an elevated PowerShell command window and run the following command.

New-NetRoute -AddressFamily IPv4 -DestinationPrefix -InterfaceAlias ‘Internal’ -NextHop


For domain-joined RRAS servers, corporate DNS servers should be configured on the Internal network interface only. No DNS servers should be configured on the external interface. If the server is not joined to a domain, DNS servers can be configured on whichever interface has connectivity to the defined DNS servers.


When the RRAS server is behind a device performing Network Address Translation (NAT), the NAT should be configured to translate only the destination address (DNAT). This allows the VPN server (or load balancer for multiserver deployments) to see the client’s original source IP address, which ensures efficient traffic distribution and meaningful log data.

Client, Service, and Protocol Bindings

All unnecessary clients, services, and protocols should be unbound from the external network interface. It is recommended that only the IPv4 and IPv6 protocols be enabled on the external interface, as shown here. Again, this reduces exposure for the server to the untrusted external network.

Always On VPN and RRAS with Single NIC


The dual NIC, multihomed configuration is generally recommended for most deployments as it offers security and performance advantages over the single NIC configuration. For organizations with less demanding security requirements, a single NIC deployment can be deployed safely without compromising functionality or supportability. In addition, a single NIC deployment may be the best option when multiple networks aren’t readily available.

Additional Information

Windows 10 Always On VPN and Windows Server Routing and Remote Access (RRAS)

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN Hands On Training

Leave a comment


  1. Some Guy

     /  August 19, 2019

    Nitpicking perhaps, but I would change “static routes to any remote internal networks should be configured” to “static routes to all remote internal networks must be configured”. 🙂

    • Perhaps. 😉 Subtle difference though (“any” to “all”). I chose “any” because there’s no requirement to define routes to “all” remote internal networks, only those that either the VPN server or VPN clients must be able to access. Does that clarify things for you? 🙂

  2. Hi Richard, first thank for all your pretty good reference articles!
    So, I’ve an issue with always On VPN users tunnel. The SSTP or IKEv2 tunnel is well connected but with split tunneling mode, I do not have any route to go to internal network. When I add it after the tunnel is up, all is fine. So, the issue is, even I add route in the XML file, never I see it in the route table on the client computer. Is it possible to add this rooute on the VPN Server? I do that too with no success. Note that my RRAS server have only 1 NIC in DMZ. Thanks for your advices 🙂 Jeff/

    • If you are adding routes in ProfileXML and they aren’t appearing on the client, it’s a good bet your XML isn’t properly formatted. That’s the only time I’ve ever seen this problem occur. If you want to send me your ProfileXML via email I’d be happy to review and provide feedback.

  3. Ludvig L

     /  December 5, 2019

    Hi Richard! Thank you for an excellent comment above about DNAT! I am trying to achieve exactly that solution in order to see the original IP of the VPN client in the border firewall instead of the IP of the RRAS server currently performing the NAT. Could you point me in the correct direction to achieve that?

    • You would have to consult the documentation provided by your firewall vendor to determine how to configure DNAT. It’s different for every solution. 🙂

  4. hey Richard, thanks so much for everything you’ve put up on this subject. You’ve got me nearly there.
    I have a server 2019 RRAS. Single NIC setup. It connects, authenticates etc all fine.
    When on the VPN, I can use private IP to get onto the RRAS server itself.
    The RRAS sever itself, can route to all the internal things it should, RDP etc all works fine.
    The RRAS is on , I have it handing out addresses.
    I can’t get to any of the other networks while on the VPN.
    I heard I had to put NAT in , so I installed NAT, made it nat IKE 4500 and 500 to the default gateway
    Still no joy.
    Not sure what else to do.

    it is in AWS if that makes a difference and the other networks are in over a transit gateway. the RRAS can contact those fine, just the client on VPN can’t

    • 0h and I have disabled class based routing. routing seems all fine on the client side via route print. the internal addresses all get shunted down the vpn tunnel to the ip address the rras assigned. It hits the server then doesn’t seem to carry on

    • For AWS you have to disable the source and destination check on the VPN server’s interface and you also have to create a routing table to ensure traffic can be routed correctly. I’m preparing an AWS implementation article as we speak. Look for that in the near future. 🙂

      • Gabriel McColl

         /  December 16, 2019

        Heya thank you for reply. That actually is disabled and route tables etc all seem fine since can route from the actual server and the route is a /16 which covers the range from rras.
        I also disabled tcp offload etc as per AWS advice re using the server as a customer gateway though realise probably doesn’t matter since it’s udp.
        I am using single nic because it’s in one external subnet. I tried disabling windows firewall temporarily too see if that made a difference but no
        I get assigned an ip from rras. I can get to the rras server. If I tracert to internal address it goes to my rras given ip fine. Then I just can’t go anywhere after that. No next hop. Would be expecting the Nat to jump ?

      • Heya so a call to AWS support solved this for me.

        VPN server was
        The route I put in for the rras to give me on VPN was

        The problem was that even though I had routed for to go local for the vpc, because wasn’t created by AWS, but by the rras, it didn’t know how to deal with it. It didn’t know it was local.

        Make the rras VPN a totally different subnet
        And then to add routes to everything (the rras server subnet included! , other subjects you want to connect to, transit gateway etc ) for that mapped to the ENI / network interface of the rras server.

        Also update the security groups to allow and you’re grand. Of course NAT could get used but I couldn’t get it working on single nic.

        There are probably better solutions but this worked for me.

      • Glad you were able to get things sorted out! 🙂

  1. Always On VPN and RRAS in Azure | Richard M. Hicks Consulting, Inc.
  2. Always On VPN RRAS Monitoring and Reporting | Richard M. Hicks Consulting, Inc.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: