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 10.0.0.0/8 -InterfaceAlias ‘Internal’ -NextHop 172.21.12.254

DNS

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.

NAT

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

Summary

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

54 Comments

  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”. 🙂

    Reply
    • 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? 🙂

      Reply
  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/

    Reply
    • 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.

      Reply
  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?

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

      Reply
  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 10.230.200.29 , I have it handing out 10.230.100.0/24 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 10.230.200.1.
    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

    Reply
    • 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

      Reply
    • 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. 🙂

      Reply
      • 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 10.230.200.10
        The route I put in for the rras to give me on VPN was 10.230.100.0/24

        The problem was that even though I had routed for 10.230.0.0/16 to go local for the vpc, because 10.230.100.0/24 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.

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

        Also update the security groups to allow 10.175.100.0 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?

    Reply
    • 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!

      Reply
      • 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 (10.0.10.0/24) from the Internet for clients but DHCP is configured for the Internal LAN for Always On VPN (192.168.10.0/24). 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.

    Reply
    • 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. 🙂

      Reply
  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.

    Reply
    • 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.

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

    Reply
    • 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?

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

      Reply
      • 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 vpn.domain.com*” 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 10.0.0.0/8, 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 58.111.222.5. 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)?

    Reply
    • I’m not sure you’ll have any trouble if your route 10.0.0.0/8 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.

      Reply
      • 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 0.0.0.0/0 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: 192.168.253.254 (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: 192.168.253.250
    – DMZ1 (DMZ-LAN): 192.168.100.250
    – DMZ2 (DMZ-WAN): 192.168.99.250
    – WAN: 192.168.33.80

    The LAN is made of:
    – 1 DC: WS 2019 – AD / ADCS / DHCP / DNS – IP: 192.168.253.1 – Static route to 192.168.100.x 192.168.100.250
    – 1 MECM – WS 2016 – IP: 192.168.253.40 (same static route)
    – 1 NPS – WS2016 – IP: 192.168.253.45 (not used for the moment)
    – 1 W10 Enterprise 1909:
    o Inside IP: 192.168.253.100 (DHCP) – GW: 192.168.253.254 – DNS: 192.168.253.1
    o Outside IP: 192.168.33.150 – GW: 192.168.33.252 – DNS:8.8.8.8 – Static route: 192.168.99.0/24 192.168.33.80
    o Added in hosts file : 192.168.99.70 = rras01.lab.com
    The VPN Profile is:

    rras01.lab.com
    IKEv2

    Certificate

    SplitTunnel

    true

    192.168.253.1
    32

    192.168.253.40
    32

    192.168.253.1, 192.168.253.40


    true

    true

    true

    The DMZ:
    – RRAS01: WS2016 / RRAS – WORKGROUP
    o NIC1: 192.168.99.70 – GW: 192.168.99.250 – No DNS (removed all other protocols as stated in this article, IPv4 and IPv6 are the only 2 remaining)
    o NIC2: 192.168.100.70 – No GW – DNS: 192.168.253.1 – Static route added: 192.168.253.0/24 192.168.100.250 (nothing removed on this interface)
    – Machine Certificate is as asked:
    o CN=rras01.lab.priv
    o DNS=rras01.lab.com
    – 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: 192.168.200.100 to 192.168.200.200
    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 192.168.200.102 and DNS 192.168.253.1

    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 😊

    Reply
    • 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

      Reply
      • 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.

      Reply
  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 to Glen Harrison Cancel reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: