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! 🙂

  5. Terry

     /  March 6, 2020

    Evening All

    Can anyone confirm the best practise here for RRAS server positioning as there seems to be a lot of ambiguity out there…

    MS recommends positioning this in the DMZ with an External interface (public IP) and Internal interface (DMZ LAN) – not connected to corporate LAN.

    Others have said to use External interface (public IP) and Internal interface (Corp LAN). I guess this would still need to route traffic via the Firewall between the interfaces to work?

    Others have said to use a single Interface (corp LAN) and NAT the traffic from the Firewall.

    Any advice?

    • There are many ways to configure the Routing and Remote Access Service (RRAS), and all of the configurations you mentioned are supported. Which one you choose is purely a design choice and is entirely up to you. All of them will work. The general recommendation is to configure two network interfaces, one external facing and one internal facing. The internal interface could be directly on the LAN, or in an internal-facing perimeter/DMZ. The external interface should be configured with a private IP address and placed in an Internet-facing perimeter/DMZ behind an edge firewall for optimal protection. Placing the RRAS server directly on the Internet with a public IP address is not recommended and should be avoided at all costs. Hope that helps!

      • Terry

         /  March 8, 2020

        Thanks Richard. I have configured RRAS VPN server to have Internal (Corp LAN) and External (DMZ LAN that is routable via firewall Public IP) interfaces.
        Ports 4500 and 500 are set to route to the External interface ( from the Internet for clients but DHCP is configured for the Internal LAN for Always On VPN ( Should RRAS route traffic between External and Internal LANs automatically or is there additional RRAS configuration required to get this working – do i need any configuration on the Firewall to route between the networks or should RRAS take care of this itself?

      • If your RRAS server has two network interfaces, you will configure the external interface with an IP address, subnet mask, and default gateway. No DNS servers should be configured on the external interface. The internal interface will have an IP address, subnet mask, but NO default gateway. Internal DNS servers should be configured on the internal interface only. You will also need to add static routes on the internal interface for any remote internal subnets. If you’ve got all that configured, RRAS should automatically handle the routing of your VPN client subnet. The VPN clients will have access to anything that’s reachable from the VPN server’s internal interface.

      • Terry

         /  March 9, 2020

        Many thanks Richard, with your recommendation i have been able to get a successful connection. The only thing remaining now is that DNS doesnt resolve host names on my Corp LAN (i can connect fine via IP).
        I would imagine this is because of Split Tunneling that is the default set up here?

      • Can you resolve names using the FQDN?

  6. Justin

     /  March 22, 2020

    Hi Richard, Thanks for another great post! I have followed your guidance from various posts and setup 2 sites that have AOVPN with the RAS(VPN) server hosted in Azure. I have configured both RAS servers with a single NIC and it works well. Would there be any benefit in using a 2nd NIC on an Azure RAS server since Azure already routes traffic between subnets in a VNET and you can be protected with NSG’s on the subnet and NIC level as well? Thinking about it I can’t see any benefit in adding the 2nd NIC on an Azure-hosted RAS server but it would be interesting to hear your take.

    • Having two NICs is recommended from a security perspective mostly to ensure that network traffic from different trust zones is physically segmented. If you don’t have requirements for that level of security, or you’re simply open to accepting the risk, then a single NIC works just fine and there’s no other operational benefit to having two NICs. You could make an argument that having two NICs can improve performance, but that would only be if you had a single NIC that was saturated, which is not easy to do in the first place. 🙂

  7. Bob

     /  March 23, 2020

    Hi Richard, Your work is great and is helping me a lot. I am using 1 Nic. Have you any instructions that could help me with the routing part please. Everything is connected but cant route to anything else when Im connected. I’m using static IP address pool with a random address space. Im not sure if this is right.

    • You’ll need to configure a route on your internal network. How that’s done depends on how your network is configured. If you are using an internal routing protocol you would advertise the prefix and next hop there. If not, you might have to add a static route to your internal routers.

  8. Glen Harrison

     /  March 26, 2020

    Hi Richard, Hope you are well. I’ve been reading many articles regarding Always-On-VPN and your name keeps cropping up. We have a single Fortinet 1500D firewall with one interface on the LAN, and another for the DMZ. Currently we have an RODC and a domain-joined SCCM DP in the DMZ. I think I’m right in saying that the RAS server needs to be domain-joined with a NIC for the DMZ, and a second NIC for the LAN. I do not like this idea and I have real security concerns having a domain-joined windows server in the DMZ facing the Internet, with a direct connection to my LAN. Should I be worried? and is there a better way? Thanks very much!!

    • Glen Harrison

       /  March 26, 2020

      The only other option I can think of, is only have one NIC on the RAS and creating a second subnet on the DMZ. This new subnet (which would give full LAN access) would be configured on the DHCP scope of the RAS server. Not sure if that’s a good idea?

      • No need. Just don’t join the RRAS server to the domain and you won’t have to worry about it. 🙂

    • There’s no need to join the Routing and Remote Access Service (RRAS) server to the domain if you don’t want to. I deploy RRAS all the time in perimeter/DMZ networks without joining it to the domain (because having a domain-joined system in a perimeter/DMZ network is a really bad idea!). The only thing you have to consider is that you can’t use certificate autoenrollment, so you’ll have to manage certificates manually. Don’t forget when they expire! 🙂

      • Tony

         /  March 27, 2020

        Just my 2 cents here, i have 2 NICs on my RRAS server, 1 connected to the corp LAN and 1 connected to the DMZ with a firewall in front of it (my firewall NATs the AOVPN ports traffic to the DMZ NIC so its not directly Internet facing). That works well.
        In my lab i set this up with a single NIC on RRAS, again using NAT on the firewall to route AOVPN port traffic to the server which works fine.
        Lots of options here.

      • Thanks for sharing! I agree, RRAS has some network deployment flexibility. There are advantages and disadvantages when using either configuration. Ultimately it is a design decision you must make that best fits your environment and requirements. 🙂

      • Glen Harrison

         /  March 27, 2020

        Thanks for the quick reply. I have a non-joined server in the DMZ already where I had to manually install the certificate so not a problem. Just to confirm, it’s ok to put a non-joined server in the DMZ with a NIC connected straight to the LAN (ie, corp network). I still feel a bit uneasy about it. What are the risks in reality of doing this?

      • It would be ideal if there were a firewall between the VPN server and the LAN so that you could monitor and log traffic between them, but it should work either way. The only risk is that you lose this visibility if you don’t have a firewall between them.

      • Glen Harrison

         /  March 27, 2020

        Sorry, I’m struggling with getting the RAS certificate installed on the server now it’s on a workgroup. I can export it from the CA ok, but I can’t just import it as it needs additional info like the external DNS names. When it was domain joined I could right-click and request new certificate, but I can’t do that now. Any ideas?

      • You can make this process easier by granting access to the certificate template to a domain-joined machine, then configuring the template to allow exporting the private key. Complete the request entirely on your domain-joined machine, then export it to PFX and import it on the VPN server. Make sure you install the root and any issuing CA certificates before you do that though!

      • Glen Harrison

         /  March 28, 2020

        Thanks very much for helping me sort this!! It’s very much appreciated. I was almost ready to start banging me head against the wall. I have got everything setup (I originally had it all working with both servers domain-joined in the DMZ). Now I have my RAS in the DMZ on a workgroup with the certificate imported, my NPS in the domain and my windows 10 laptop for testing. The error I’m seeing is event id 18 on windows, and looking at the NPS logs indicates “a radius message was recieved from the invalid radius client IP address *IP of my external router address which is used to NAT my public*” I’m not sure why the client is contacting NPS rather than the RAS server. I’ve double checked all settings and they look good. My company is willing to pay you a consultancy fee for helping with this.

      • It sure sounds like the NPS server isn’t configured to accept RADIUS requests from the internal IP address of your RRAS VPN server. If you’d like some assistance resolving this, reach out to me directly. Always happy to help!

      • Glen Harrison

         /  March 30, 2020

        I have it working if I move the NPS server into the DMZ. When I move it back to the LAN is when it stops. I’ve ensured the Radius has the updated IP addresses, and we opened up all ports between the DMZ and LAN both ways for testing. No matter what I do, I can’t get it working with the NPS server in the LAN. Microsofts error message about authentication was wrong.

      • Unusual. Is it a routing or firewall issue perhaps?

      • Glen Harrison

         /  March 30, 2020

        The firewall is open, and I can ping the NPS server from the RAS server fine, and I can also ping the RAS server from NPS. It’s just when I move the NPS into the LAN, the windows 10 laptop I’m using has the error 18, and in the NPS logs it sees the connection coming from the external router IP rather than the IP of the RAS server. Weird.

      • Does your RRAS server have two network interfaces? I can’t seem to recall if you shared that with me or not yet…

      • Glen Harrison

         /  March 30, 2020

        It’s a VM. I have tried with one NIC and two

      • That’s odd for sure. Would be interesting to see a network trace when it fails just to see what’s happening on the wire.

      • Glen Harrison

         /  March 31, 2020

        I’ve finally managed to get it working 🙂 It was a setting on our firewall which was hiding the clients IP address, replacing it with one from the firewall itself. Think it’s a default setting when creating a NAT rule. Turned it off and it started working straight away. My internet client is getting an IP on the DMZ subnet (using DHCP server on RAS), so I just need to figure out what I’m going to do next…..currently the RAS only has one NIC, and I kinda feel safer with it like that.

      • Great to hear! 🙂

  9. Richard,

    I am working on a POC of Always On VPN. Your articles were very helpful, thank you. Currently I have a RRAS server with one NIC in the DMZ and one on an internal subnet. I’m trying to figure out the best way to handle routing. The DMZ is part of, so I can’t blindly route all of the private ranges through the internal NIC. What would be the best way to cleanly route this? I’ve done similar things on NetScaler, but NetScaler has policy based routing and enables you to route by source IP.

    Another complication is we have special internal routing (on the actual routers) for some ‘public’ IP ranges. As an example let’s take This public IP is advertised on a private line internally and traffic doesn’t go out to the internet for that destination, but over a private line. What is the best way to handle these cases without loading up a huge routing table into RRAS (and having to maintain it)?

    • I’m not sure you’ll have any trouble if your route internally, even if there is a portion of that space in the DMZ. Even though there would be some overlap, traffic going to the DMZ would have a more specific route than the internal. I’m not certain about this, but you can certainly test for yourself and see how it goes.

      As for the ‘public’ route, there’s no harm in adding those to the routing table either. FYI, do that in Windows with New-NetRoute as opposed to configuring them in RRAS. If your clients need to reach this address over the VPN tunnel you can add that network to their routing table as well.

      • Thanks, I tried it and the private routes did in fact work fine.

        For the private line ‘public’ routes, I was hoping there was something I could come up where I wouldn’t have to maintain our routing table on another set of devices.

        The other issue here is that with two NICs and routing table where goes to the DMZ gateway causes all the VPN client IPs to go out the DMZ NIC for internet which causes asymmetric routing. What can I do about this?

      • Having two NICs is always problematic when you are trying to route Internet traffic over the VPN. It is recommended that this be avoided as much as possible to avoid just these kinds of issues. However, if you have no choice, the best recommendation is to switch to single NIC.

      • So, I spent more time on this today. I probably will be going with a single NIC, between this problem and the fact that there is no real security benefit to using two NICs since it will be behind firewall which allows for additional inspection and control.

        What I did do for now though is use the policy-based forwarding option on our PaloAlto firewall. We now have a PBF (policy-based forwarding) rule set for traffic coming from the DMZ zone/internal IP subnet to use the internal interface as the egress with the internal network gateway as the next hop… this works perfectly. Like I said we’re going to move to single NIC for simplicity, but this is an option for others who are having this issue. I’ve accomplished similar things using PBR (policy based routes) (PBR) in NetScaler. If only Windows had policy-based routing…

      • Awesome. Thanks for sharing that tip!

  10. aventador06

     /  May 6, 2020

    Dear Richard Hicks
    Thank you very much for your articles.
    They really are much more helpful than the poor MS documentation we could find on Always On VPN.
    I need your help to validate my POC if you agree to. Sorry for this long post but I like it to be as complete as possible… so you can take a coffee break if you need while reading this 😊
    Our goals are:
    – To implement Always On VPN by the end of the month to provide greater work from home experience
    – To be able to manage our outside computers as if they were in the office (using MECM mainly)
    I’ll first be offering Device Tunnels then I’ll check with the network expert regarding the user tunnels as we already have Radius servers (Cisco ACS / ASA / FirePower and so on) with much more options than the simple NPS server.
    We have a design where the RRAS server will have 2 NICs :
    – 1 connected to a FW between the DMZ and the WAN
    – 1 connected to a FW between the LAN and the DMZ.

    I’m trying to reproduce a full Hyper-V Lab reflecting this network.
    I have installed the following:
    – LAN address: 192.168.253.x/24
    – DMZ to LAN address: 192.168.100.x/24
    – DMZ to WAN address: 192.168.99.x/24
    – WAN address: 192.168.33.x/24 (I’ll be simulating the Web here)

    – Domain Name: lab.priv
    – LAN Default GW: (IP Address of my NAT Hyper-V interface that provides internet connectivity)

    The VMs:
    The FW: I’m trying to use a PFSense VM. It gives all the functionalities I need.
    It has 4 NICs:
    – LAN:
    – DMZ1 (DMZ-LAN):
    – DMZ2 (DMZ-WAN):
    – WAN:

    The LAN is made of:
    – 1 DC: WS 2019 – AD / ADCS / DHCP / DNS – IP: – Static route to 192.168.100.x
    – 1 MECM – WS 2016 – IP: (same static route)
    – 1 NPS – WS2016 – IP: (not used for the moment)
    – 1 W10 Enterprise 1909:
    o Inside IP: (DHCP) – GW: – DNS:
    o Outside IP: – GW: – DNS: – Static route:
    o Added in hosts file : =
    The VPN Profile is:







    The DMZ:
    – RRAS01: WS2016 / RRAS – WORKGROUP
    o NIC1: – GW: – No DNS (removed all other protocols as stated in this article, IPv4 and IPv6 are the only 2 remaining)
    o NIC2: – No GW – DNS: – Static route added: (nothing removed on this interface)
    – Machine Certificate is as asked:
    o CN=rras01.lab.priv
    – Root CA (LAB-CA) added to VPNAuthProtocol using the command you provide:
    $VPNRootCertAuthority = “LAB-CA”
    $RootCACert = (Get-ChildItem -Path cert:LocalMachine\root | Where-Object {$_.Subject -Like “*$VPNRootCertAuthority*” })
    Set-VpnAuthProtocol -UserAuthProtocolAccepted Certificate, EAP -RootCertificateNameToAccept $RootCACert -PassThru
    – IP range delivered to the VPN clients: to
    I don’t think I forgot anything.
    What’s working:
    – I’ve opened UDP 500/4500 from 192.168.33.x to 192.168.99.x.
    – I’ve allowed ICMP from WAN to DMZ1 and LAN/DMZ2 (and reverse)
    – I’ve opened TCP/UDP from DMZ2 to LAN
    – I’ve opened TCP/UDP from LAN to DMZ2 (I don’t know what to filter exactly)
    – My VPN is up with IP and DNS

    What’s not working:
    – I cannot ping anything in my LAN
    My questions:
    1) Is my RRAS correctly configured regarding network configuration?
    2) Regarding the 192.168.200.x delivered IPs: Do I need to NAT them? Is it the reason why I cannot ping anything?
    3) Can you provide the list of ports to open between LAN and DMZ2?
    4) I had to keep the Remote Access connections (Inbound only) checked on WAN Miniport (IKEv2) for this VPN to come UP. Everything I’ve read about this is to uncheck this box if I want to be able to manage my computers from the MECM server. Is it normal?
    5) Somewhere, I’ve read a comment about disabling the other WAN Miniport and only keep IKEv2 and SSTP. Do you recommend this?

    Thanks for reading this really very long post and for your help.
    My post is as long as all the other comments……sorry 😊

    • aventador06

       /  May 8, 2020

      Hi again,
      In fact, I’m completely lost in the routing.
      The VPN client gets the 192.168.200.x address and it stops here.
      Questions :
      1) Do I need to add Routing feature to the RRAS ? (I’ve only added Direct Access and VPN)
      2) Do I need to specify a route to reach this 192.168.200.x subnet ?
      Thanks for your help

      • You should not need to add the Routing feature for VPN to work. You’ll need to ensure that your VPN servers has the necessary routes to reach the internal resources first. Once that’s in place, the client configuration will also need routes to internal networks as well.

    • Some of the formatting is lost when you post here in the comments, sorry. However, I don’t see anything inherently wrong with your configuration. If you are unable to access resources on the LAN, I would first make sure you can access those resources from the VPN server itself. If you can, it might be an issue with the client configuration, specifically routing configuration as defined in your ProfileXML. Also, there should be no need to NAT anything for Always On VPN to work.

      It is a good idea to disable any protocols that aren’t being used. For example I routinely disable all L2TP, PPTP, and GRE ports as I never use those for remote access.

  11. Javier

     /  August 11, 2020

    Hi Richard,

    I just need some confirmation on 2 things: one is related to your post and the other one is related to my deployment.

    1.- In your post you recommend to add a static route on RRAS server in order to be able to reach necessary internal subnets using ‘New-NetRoute’

    It is not clear to me if AOVPN clients will get this route too or if they get routes only from Routing and Remote Access -> RAS Server -> IPv4 -> Static Routes.

    Could you please confirm as I do not want to break the currently working infrastructure?

    2.- In our infrastructure, our RRAS servers (with 2 interfaces) are configured with ‘VPN Access’ and ‘NAT’.

    NAT is performed on the Internal interface. These servers were handed over to my group time ago and, as they were working and I had to fix a lot of other issues, I didn’t change this.

    But since the beginning I have been wondering if NAT should changed to the external interface to increase security. What do you think?

    Thanks a lot for your help with the information you provide with this site. It’s fantastic!!!

    • Routing on the server and client are two different things. First, the VPN server must have routes to any remote internal subnets it needs to access. Also, it must have routes to any remote internal subnet that VPN clients need to access. In addition, VPN clients must be configured to route traffic for any internal subnets over the VPN. Any traffic you choose to route over the client VPN tunnel must also be reachable/routable from the VPN server.

  12. Mike

     /  December 23, 2020

    Hi Richard,
    Thanks for your posts on Alwayson VPN.

    I am a network engineer so I am trying to wrap my head around one thing.

    Does the VPN gateway “NAT” clients as they access the internal resources?

    I am not sure if my internal network needs a reverse route for the client subnets as well. They can already reach the internal DMZ where the VPN gateway is located.

    For eg.
    If VPN gateway is in the DMZ (single arm setup).
    If the client pool is

    When a client lets say will try to access an internal resource say ( internal network) , will the internal resource see the request coming from the client ip ( or does the VPN gateway hides it behind

    Once I understand this, I can setup the required routing.
    There is surprisingly less documentation on this.

    • The default and correct configuration would be to route traffic, not NAT. You can do this, but it isn’t enabled by default and I don’t recommend it either. With that, you will need a route in your core network that directs VPN client subnet traffic back to the VPN server.

  13. morethanthesky

     /  March 29, 2021

    Have you ever seen with the ‘Internal’ interface is ‘not available’? It’s not giving itself an IP. In comparing my working 2016 server and the new 2019 server I’m standing up, the route print table is missing the .1 IP from the static routes that the 2016 server had assigned to its own interface from its own pool. I’m not sure what to do.

    • I’ve not seen that myself, no. When RRAS does strange things like this, sometimes it is best to just wipe and reload. It sounds harsh, but it is easy enough to reconfigure. I find it takes less time to do this than to troubleshoot odd issues like this. 🙂

      • morethanthesky

         /  April 1, 2021

        Thank you so much for answering back. I feel like I’m speaking with a celebrity 🙂 I found several things wrong with the system – I don’t know if that will help. This 2019 server was replacing a corrupted 2016 server, so I’d given it the same range of IPs to hand out that the now retired 2016 had had. But in the main switch, the network admin had assigned those IPs to the IP of the old server. Additionally, though the VMWare admin had changed the IP of the internal NIC and we changed it in Network > ipv4 > properties, the registry still had the old IP. A combination of small errors seemed to have led to the whole problem, but today it seems to be working /fingerscrossed!

      • Glad to hear you got it sorted out. Thanks for the update! 🙂

  14. Chris

     /  April 22, 2021

    Hi Richard, I just spun up a VPN server to replace an existing, and in RRAS, the internal interface is showing as Non-operational. Banging my head on this one. Thanks

  15. Scott S

     /  June 25, 2021

    I have single nic RRAS server Setup and need help with 1 thing. I have the RRAS server handing out ip addresses. Wtith split tunnling turned on. Inside network is I have some other internal networks and I can get to all the networks that are 10.x.x.x but the one network Is not going over the tunnel when I do a tracert. I have added a static route on the RRAS server and under the RRAS console but does not help, If I add the route on the client it works fine.
    I don’t want to use a DHCP server with the options added because I would like to have the VPN clients have a seperate range so I tell when someone is on the vpn. I could try to add a GPO based on IP address to add the route that is th only solution I can think of if the RRAS server wont give it out.. Thanks..

    • Adding the route on the client is required. You can specify routes in the Always On VPN configuration profile in Microsoft Endpoint Manager, or you can add them to your XML if you are using PowerShell/SCCM.

      • Scott S.

         /  July 13, 2021

        I actually did not configure the allways-on VPN, I thnk MS was not going to support it anymore. So I installed the PDQ version that basicly setup up the same thing. But still having an issue with routes on the client I have added a persistant route to and when I reboot a client it does not show up as an active route just under persistant nit sure why this would be? The gateway is an ip address on my internal network. If I add the route then it works.

      • How are you adding the route? If you are using New-NetRoute or “route add” that won’t work. You’ll need to add the route to the VPN profile itself using the Add-VpnConnectionRoute PowerShell command. Give that a shot and it should work.

      • Scott S

         /  July 13, 2021

        Here is the command.. route add MASK I’m guessing because there is no route to the network when the copmuter boots that it does not add the route to active. but I did it that way so the same route would work inthe building and over the VPN.

      • You answered my question. 🙂 Use Add-VpnConnectionRoute instead. Using “route add” doesn’t persist the route for VPN connections.

  16. Scott S

     /  July 19, 2021

    Thank you that worked.

  17. Christoph

     /  November 8, 2021

    If the server is not joined to a domain, is it recommended to have the Connection-specific DNS Suffix configured on the internal interface of the RRAS Dual Nic server.

    • It’s a good idea, yes. It would only be required if the non domain-joined server needed to resolve internal Active Directory names though. If that’s not the case then you can leave it off.

  18. Liam Stratford

     /  March 16, 2022

    Hi Richard

    I have a problem with my Always on VPN setup in that any client connected will not route traffic to the internal network.
    I’ve tried all sorts of configs with class-based and class-less routing, with and without traffic filters in the XML profile, but nothing is working – I can’t even ping the end of the tunnel.

    This is a Device Tunnel and configured in the context of the local system account on the device. I’ve used a combination of the Microsoft literature and articles from Richard Hicks to implement. The VPN RRAS servers themselves have an external leg in the org’s DMZ and an internal NIC for intranet routing – this works fine.
    Static routes have all been added on the RRAS VPN server, I’ve also tried adding them on the client too but as I cannot ping the end of the tunnel this does not work.

    Type: IKEv2
    Auth: Certificate
    Load balanced via Citrix Netscaler

    I cannot understand why traffic hits the VPN adapter and then drops straight away.

    No stability or connection issues, solid once established but I just cannot work out the routing.

    Any help will be greatly appreciated as I’m currently all out of ideas. I can post any log files if needed too


    • I would start by (temporarily) disabling the Windows firewall on the RRAS server (I’m assuming you are using RRAS?). See if that enables you to ping the VPN server’s virtual interface over the tunnel. From there, you might want to take a network trace on the RRAS server to see if the traffic is egressing. It could be a routing issue if you are using a unique VPN client IP subnet. Just a few things to think about.

  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

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading