I’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.
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
Some Guy
/ August 19, 2019Nitpicking 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”. 🙂
Richard M. Hicks
/ August 19, 2019Perhaps. 😉 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? 🙂
Jeff Aprea
/ November 7, 2019Hi 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/
Richard M. Hicks
/ November 10, 2019If 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.
Ludvig L
/ December 5, 2019Hi 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?
Richard M. Hicks
/ December 5, 2019You would have to consult the documentation provided by your firewall vendor to determine how to configure DNAT. It’s different for every solution. 🙂
Gabriel
/ December 13, 2019hey 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
Gabriel
/ December 13, 20190h 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
Richard M. Hicks
/ December 15, 2019For 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, 2019Heya 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 ?
Gabriel McColl
/ December 16, 2019Heya 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.
Richard M. Hicks
/ December 17, 2019Glad you were able to get things sorted out! 🙂
Terry
/ March 6, 2020Evening 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?
Richard M. Hicks
/ March 7, 2020There 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, 2020Thanks 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?
Richard M. Hicks
/ March 8, 2020If 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, 2020Many 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?
Richard M. Hicks
/ March 9, 2020Can you resolve names using the FQDN?
Justin
/ March 22, 2020Hi 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.
Richard M. Hicks
/ March 23, 2020Having 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. 🙂
Bob
/ March 23, 2020Hi 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.
Richard M. Hicks
/ March 23, 2020You’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.
Glen Harrison
/ March 26, 2020Hi 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, 2020The 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?
Richard M. Hicks
/ March 26, 2020No need. Just don’t join the RRAS server to the domain and you won’t have to worry about it. 🙂
Richard M. Hicks
/ March 26, 2020There’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, 2020Just 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.
Richard M. Hicks
/ March 27, 2020Thanks 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, 2020Thanks 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?
Richard M. Hicks
/ March 27, 2020It 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, 2020Sorry, 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?
Richard M. Hicks
/ March 27, 2020You 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, 2020Thanks 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.
Richard M. Hicks
/ March 28, 2020It 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, 2020I 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.
Richard M. Hicks
/ March 30, 2020Unusual. Is it a routing or firewall issue perhaps?
Glen Harrison
/ March 30, 2020The 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.
Richard M. Hicks
/ March 30, 2020Does 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, 2020It’s a VM. I have tried with one NIC and two
Richard M. Hicks
/ March 31, 2020That’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, 2020I’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.
Richard M. Hicks
/ March 31, 2020Great to hear! 🙂
Mark DePalma
/ April 11, 2020Richard,
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)?
Richard M. Hicks
/ April 11, 2020I’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.
Mark DePalma
/ April 12, 2020Thanks, 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?
Richard M. Hicks
/ April 13, 2020Having 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.
Mark DePalma
/ April 13, 2020So, 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…
Richard M. Hicks
/ April 13, 2020Awesome. Thanks for sharing that tip!
aventador06
/ May 6, 2020Dear 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 😊
aventador06
/ May 8, 2020Hi 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
Richard M. Hicks
/ May 14, 2020You 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.
Richard M. Hicks
/ May 14, 2020Some 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.
Javier
/ August 11, 2020Hi 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!!!
Richard M. Hicks
/ August 11, 2020Routing 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.
Mike
/ December 23, 2020Hi 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 192.168.1.1/24 in the DMZ (single arm setup).
If the client pool is 10.1.1.0/24
When a client lets say 10.1.1.1 will try to access an internal resource say 172.16.1.1/24 ( internal network) , will the internal resource see the request coming from the client ip (10.1.1.1) or does the VPN gateway hides it behind 192.168.1.1.
Once I understand this, I can setup the required routing.
There is surprisingly less documentation on this.
Richard M. Hicks
/ December 28, 2020The 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.
morethanthesky
/ March 29, 2021Have 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.
Richard M. Hicks
/ April 1, 2021I’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, 2021Thank 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!
Richard M. Hicks
/ April 2, 2021Glad to hear you got it sorted out. Thanks for the update! 🙂
Chris
/ April 22, 2021Hi 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
Richard M. Hicks
/ April 23, 2021No idea why that would be. IPv6 isn’t disabled, is it?
Scott S
/ June 25, 2021I 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 10.1.0.0/20 I have some other internal networks and I can get to all the networks that are 10.x.x.x but the one 192.168.50.0/23 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..
Richard M. Hicks
/ June 26, 2021Adding 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, 2021I 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 192.168.50.0/32 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.
Richard M. Hicks
/ July 15, 2021How 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, 2021Here is the command.. route add 192.168.50.0 MASK 255.255.254.0 10.1.0.1 I’m guessing because there is no route to the 10.1.0.0 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.
Thanks
Richard M. Hicks
/ July 15, 2021You answered my question. 🙂 Use Add-VpnConnectionRoute instead. Using “route add” doesn’t persist the route for VPN connections.
Scott S
/ July 19, 2021Thank you that worked.
Christoph
/ November 8, 2021If 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.
Richard M. Hicks
/ November 8, 2021It’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.
Liam Stratford
/ March 16, 2022Hi 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
Thanks
Richard M. Hicks
/ March 16, 2022I 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.