Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, September 25, 2018 12:50 PM | 1 vote
I'm attempting to setup AlwaysOn VPN using 2016 server for my RAS server.
I can never get the client to connect. I always get the error 809 in the event logs and the error in Windows 10 is that firewalls, NAT or routers are preventing the connection.
There is a firewall in front of the RAS server and it is allowing UDP 4500, 500 and TCP 443, the RAS server has a DMZ interface and a LAN interface.
I have tried setting the gateway on each interface one at a time but it makes no difference. (which interface should have the gateway assigned?)
I can see vpn chatter for port 500 and 4500 via wireshark on botht he client and the RAS server.
I see no entries in the NPS log for a client trying to connect.
I do see the NPS log complain about the RADIUS client for the RAS server when I toggle gateway addresses between the interfaces.
I'm trying to get user tunnels working with zero success. The funny thing is, I enabled machine certificate authentication on the RAS server and then switched the client profile to use machine certificates instead of PEAP and I see a device show up in the RAS cosole even though Windows reports the same failure to connect message due to firewall, NAT, router etc.
The device doesn't stay there very long and I only see what looks to be outbound traffic, nothing inbound when I look at the device connection status.
I followed this guide for the most part. https://www.petenetlive.com/KB/Article/0001399
After reviewing the Microsoft document and some other guides it seems like I have everything configured correctly but it still doesn't work.
I also tried the registry key for AssumeUDPEncapsulationContextOnSendRule set to 2 but it made no difference.
The certificate issued to the NPS server was issued by a subordinate CA from the root CA though I'm only presented with options to select the root CA on the client connection. Not sure if that matters or not.
Any guidance or ideas would be much appreciated.
All replies (23)
Wednesday, October 3, 2018 6:01 PM ✅Answered | 1 vote
Good, if you suspect network ports / firewall / traffic, try SSTP instead of IKEv2, it is more friendly. Remember to enable SSTP ports in VPN server as well, if you have only IKEv2 opened.
MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.
The issue has been resolved and I hope this information helps someone else in the future.
The problem was this:
The RAS server was 2016 server and there were IKE AUTH UDP packets that were too large to be transfered so they were fragmented using IKE fragmentation at the IP level.
The fix (shout out to Richard Hicks) was to enable IKEv2 Fragmentation which is designed to alleviate this very issue.
Unfortunately, Windows Server 2016 does not support IKEv2 Fragmentation.
Windows Server 1709 and higher supports IKEv2 fragmentation. But it only works when it is enabled on the server with a registry key. HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\ikev2\EnableServerFragmentation DWORD = 1
After I built a Windows Server 2019 VM and configured RAS I created that registry key and restarted the server. From that point forward the Windows 10 client connected with no issue.
Some useful links:
https://msdn.microsoft.com/en-us/library/mt846268.aspx
https://msdn.microsoft.com/en-us/library/cc233476.aspx
Wednesday, September 26, 2018 1:53 AM
Hi,
Thanks for your question.
Please refer to the links below:
**Configure the Remote Access Server for Always On VPN **
/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-ras
Configure the Internal Perimeter Network Firewall
/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-dns-firewall
Best regards,
Travis
Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Wednesday, September 26, 2018 12:04 PM
Hi,
Thanks for your question.
Please refer to the links below:
**Configure the Remote Access Server for Always On VPN **
/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-ras
Configure the Internal Perimeter Network Firewall
/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-dns-firewall
Best regards,
Travis
Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Thank you but I already have. I continue to get the error about not being able to connect due to firewall, NAT, routers and the event log shows event id 809. However, a device was able to make a connection using machine certificates. It disconnected quickly but it did show up in the console for roughly 20-30 seconds.
I have never been able to get a user tunnel established using IKEv2.
Thursday, September 27, 2018 8:47 AM
Hi,
Thanks for your reply.
Have you updated recently?
Devices that rely on IKE2 to establish VPN connections may lose network connectivity after installing the updates KB 4343893 and KB 4457142.
Currently Microsoft has not updated the patch. It seems that uninstalling the update is the only way.
Best regards,
Travis
Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Thursday, September 27, 2018 12:01 PM
Hi,
Thanks for your reply.
Have you updated recently?
Devices that rely on IKE2 to establish VPN connections may lose network connectivity after installing the updates KB 4343893 and KB 4457142.
Currently Microsoft has not updated the patch. It seems that uninstalling the update is the only way.
Best regards,
Travis
Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
The client is fully patched 1803. It looks like these patches are for 1709.
Do you know if there are patches for 1803 that break the same functionality?
I sort of gave up yesterday after banging on this for a couple days. Everything looks to be configured correctly and the user based IKEv2 tunnels just wont come up with error code 809.
An IKEv2 device tunnel seemed to get established using machine certificates in a one-way tunnel (probably a networking issue) but it did successfully establish and show up in the console. No luck at all with this fully patched 1803 Windows 10 Enterprise client and user based IKEv2 tunnels. I just can't make them work.
Thursday, September 27, 2018 1:10 PM
Wireshark on the RAS server shows the following on the outside interface when the client attempts to connect.
The client is connected to a Verizon mobile hotspot on an iPhone.
Thursday, September 27, 2018 9:14 PM
I realized the NPS server was not registered with AD so I registered it. That had no impact.
On the RAS server every time a client tries to connect this event happens.
EventID 20255
UserName: <Unauthenticated User>. Negotiation timed out.
Friday, September 28, 2018 7:52 AM
Hi,
Please refer to the link below:
/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc733698(v=ws.10)
Best regards,
Travis
Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Friday, September 28, 2018 10:01 AM
Hi, are we talking about User Tunnel, right? How about if you first take NPS off from entire set and allow VPN to authentificate access itself? When "VPN server only" - scenario starts working, last thing is to add NPS and tight it to the VPN server authorization.
MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.
Friday, September 28, 2018 3:15 PM
Hi, are we talking about User Tunnel, right? How about if you first take NPS off from entire set and allow VPN to authentificate access itself? When "VPN server only" - scenario starts working, last thing is to add NPS and tight it to the VPN server authorization.
MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.
Yes. I will give this a shot. I may be calling Microsoft today as well.
I get the 20255 error on the RAS server with the unauthenticated user
The client gets the 809 error.
I feel like this is an issue with authentication and NPS. I see no evidence that the RAS server is trying to authenticate with NPS.. the NPS server log only shows messages about the RAS server client IP not matching when I was troubleshooting and changing IP addresses of the interfaces on the RAS server. Other than that there are no messages.
The NPS server accounting log file shows this (edited to remove IP's/names):
"NPSSERVER","IAS",09/28/2018,10:07:02,4,,,,,,,"RASSERVER","IP_of_INTERNAL_RAS_INTERFACE",,0,"IP_of_INTERNAL_RAS_INTERFACE","RADIUSCLIENTNAME_of_RASSERVER",,,,,,,,,0,,,,,,7,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,2,,,,
"NPSSERVER","IAS",09/28/2018,10:07:19,4,,,,,,,,"IP_of_EXTERNAL_RAS_INTERFACE",,0,"IP_of_INTERNAL_RAS_INTERFACE","RADIUSCLIENTNAME_of_RASSERVER",,,,,,,,,0,,,,,,7,,,,"1",,,,,,,,,,,,,,,,,,,,,,,,,,2,,,,
"NPSSERVER","IAS",09/28/2018,10:37:36,4,,,,,,,,"IP_of_EXTERNAL_RAS_INTERFACE",,0,"IP_of_INTERNAL_RAS_INTERFACE","RADIUSCLIENTNAME_of_RASSERVER",,,,,,,,,0,,,,,,8,,,,"1",,,,,,,,,,,,,,,,,,,,,,,,,,2,,,,
"NPSSERVER","IAS",09/28/2018,10:37:39,4,,,,,,,,"IP_of_EXTERNAL_RAS_INTERFACE",,0,"IP_of_INTERNAL_RAS_INTERFACE","RADIUSCLIENTNAME_of_RASSERVER",,,,,,,,,0,,,,,,7,,,,"1",,,,,,,,,,,,,,,,,,,,,,,,,,2,,,,
"NPSSERVER","IAS",09/28/2018,10:40:28,4,,,,,,,,"IP_of_EXTERNAL_RAS_INTERFACE",,0,"IP_of_INTERNAL_RAS_INTERFACE","RADIUSCLIENTNAME_of_RASSERVER",,,,,,,,,0,,,,,,8,,,,"1",,,,,,,,,,,,,,,,,,,,,,,,,,2,,,,
"NPSSERVER","IAS",09/28/2018,10:40:31,4,,,,,,,,"IP_of_EXTERNAL_RAS_INTERFACE",,0,"IP_of_INTERNAL_RAS_INTERFACE","RADIUSCLIENTNAME_of_RASSERVER",,,,,,,,,0,,,,,,7,,,,"1",,,,,,,,,,,,,,,,,,,,,,,,,,2,,,,
Friday, September 28, 2018 3:28 PM
Hi,
Please refer to the link below:
/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc733698(v=ws.10)
Best regards,
Travis
Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Thank you. I cannot identify a mismatch anywhere. Unless it is a certificate problem that I cannot see via logs.
Friday, September 28, 2018 8:06 PM
I created a brand new NPS server and configured it. I verified connectivity between it and the RAS server
I configured the NPS server to do logging to a folder on C:\ and no log file has been created. There are also no events in the NPS event log in event viewer.
This is after multiple attempts to connect with the VPN client.
The RAS server still says the same error 20225 (Unauthenticated user) negotiation timeout.
I feel like it is failing before it even tries NPS/RADIUS with error code 809 on the client.
Could it be a certificate issue? I feel like I have the three templates configured as they should be and verified that NPS, RAS and the user all have the certs they need.
The VPN server certificate is CN=publicdnsname.public.com with subject alt set to DNS publicdnsname.public.com and the public IP
The RAS server connectivity looks like this:
client --> pub dns record --> public ip --> firewall --> NAT --> ip of external interface on RAS server
The ras server also has an internal network interface
The firewall is forwarding UDP 500, UDP 4500 and I can see the traffic with wireshark on the external interface when a client attempts to connect.
There is also an outbound NAT and a PTR record to make sure the external interface of the RAS server appears as the same public IP and dns record.
The client is windows 10 1803 fully patched.
The tunnel is IKEv2 and configured per the documentation.
The server is configured to only listen and accept IKEv2
The server is configured to do RADIUS and is pointed to the new radius server
The client profile has that new radius server configured in the profile and the root certificate checked off.
The certificates for all of these are issued by a subordinate CA from the root, does that matter? The client only offers selecting the root CA and not the subordinate.
Monday, October 1, 2018 5:58 AM
I suggest you go through ALO VPN deployment whitepaper and check that you did everything right, or re-do the deployment if this is a lab or it easy to archive. Pay extra care on documents when creating certificate templates for different purpose - they must match with the documentation.
https://gallery.technet.microsoft.com/Always-On-VPN-Deployment-e681bc7d (note the 2017 date)
Couple of things crossing my mind;
1. Do VPN server and NPS server resolve eachother name&IP from DNS?
2. Turn off firewall in NPS for test purpose
3. Does authentification methods match in Client, VPN and NPS. They must obay similar authorization protocol. (perferred is IKEv2 and EAP. SSTP and MS-chapv2 is step back).
That event id 809 and 20225 sounds familiar, I had EAP authorization problem in my lab and I solved by deleting certs from personal store at the Win10 side and re-enrolled them.
MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.
Monday, October 1, 2018 3:56 PM
I suggest you go through ALO VPN deployment whitepaper and check that you did everything right, or re-do the deployment if this is a lab or it easy to archive. Pay extra care on documents when creating certificate templates for different purpose - they must match with the documentation.
https://gallery.technet.microsoft.com/Always-On-VPN-Deployment-e681bc7d (note the 2017 date)
Couple of things crossing my mind;
1. Do VPN server and NPS server resolve eachother name&IP from DNS?
2. Turn off firewall in NPS for test purpose
3. Does authentification methods match in Client, VPN and NPS. They must obay similar authorization protocol. (perferred is IKEv2 and EAP. SSTP and MS-chapv2 is step back).That event id 809 and 20225 sounds familiar, I had EAP authorization problem in my lab and I solved by deleting certs from personal store at the Win10 side and re-enrolled them.
MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.
I redid all of the certificates and checked over nps and ras again as well as the client.. I even tried a 1709 computer. Same error.
Does there need to be a DNS record internally for the public DNS name? if so, what IP should it point to?
I have the external DNS records created (A & PTR) but not an internal DNS record for the public DNS name that is defined in the RAS server cert.
Tuesday, October 2, 2018 5:32 AM
Does there need to be a DNS record internally for the public DNS name? if so, what IP should it point to?
I have the external DNS records created (A & PTR) but not an internal DNS record for the public DNS name that is defined in the RAS server cert.
Public DNS adress record does not have to be in your internal DNS zone. Your clients must resolve your VPN.service.com etc. public record externally at least. Same as with DA.
Have you ensured, that your client connections to VPN server works without NPS? I suggest you do that first.
MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.
Tuesday, October 2, 2018 2:18 PM
Does there need to be a DNS record internally for the public DNS name? if so, what IP should it point to?
I have the external DNS records created (A & PTR) but not an internal DNS record for the public DNS name that is defined in the RAS server cert.
Public DNS adress record does not have to be in your internal DNS zone. Your clients must resolve your VPN.service.com etc. public record externally at least. Same as with DA.
Have you ensured, that your client connections to VPN server works without NPS? I suggest you do that first.
MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.
It looks like we have possibly identified the cause of this issue.
I am actively working with Microsoft and while we have not resolved this yet, it seems that the cause it likely due to a larger than usual UDP packet size being dropped somewhere along the way (firewall/router) due to its size.
I will post an update when I have confirmation of this.
Wednesday, October 3, 2018 6:19 AM
Good, if you suspect network ports / firewall / traffic, try SSTP instead of IKEv2, it is more friendly. Remember to enable SSTP ports in VPN server as well, if you have only IKEv2 opened.
MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.
Thursday, October 4, 2018 5:38 AM
Awsome, thangs for sharing!
MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.
Thursday, October 4, 2018 12:38 PM
Awsome, thangs for sharing!
MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.
I should point out that the IKE fragmentation is supposed to work anyway from what I understand it is possible that there was still issues with network devices (firewalls/routers) dropping fragented UDP packets OR as Richard Hicks pointed out more commonly long certificate chains (though I am not sure if I suffered from that or not, I do not think I did).
The working solution takes advantage of the newer IKEv2 fragmentation where it handles fragmentation at the IKE level instead of the IP level.. alleviating the issue with the larger packets and MTU path issues.
Do you know if the Windows "routing" feature is required for always on VPN? I find no documentation to support that it is required but Microsoft support just said that it is.
UPDATE: Microsoft confirmed they were incorrect and routing is not required.
Thursday, October 4, 2018 4:16 PM
Do you know if the Windows "routing" feature is required for always on VPN?
I believe routing is not required.
I´m curious, would SSTP solve your problem instead of IKEv2 in this case?
MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.
Thursday, October 4, 2018 5:11 PM
Do you know if the Windows "routing" feature is required for always on VPN?
I believe routing is not required.
I´m curious, would SSTP solve your problem instead of IKEv2 in this case?
MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.
SSTP probably would have solved the tunnel issue that IKEv2 fragmentation resolved but by using IKEv2 fragmentation I should be able to have it failback to SSTP if IKEv2 doesn't work for some reason.
My understanding is that IKEv2 performs better and is more secure. Also tolerates connectivity issues better.
Friday, November 8, 2019 10:46 PM
Adding this link for reference.
https://directaccess.richardhicks.com/2019/02/11/always-on-vpn-and-ikev2-fragmentation/
Enjoy!
Richard M. Hicks
Founder and Principal Consultant - Richard M. Hicks Consulting, Inc.
directaccess.richardicks.com
Monday, November 11, 2019 7:21 AM
My understanding is that IKEv2 performs better and is more secure. Also tolerates connectivity issues better.
Yes, but SSTP is more compatible. So that connectivity issue is not like that, probably it is better chance to establish the connection with SSTP than IKEv2.
MCSE Mobility 2018. Expert on SCCM, Windows 10, ALOVPN, MBAM.