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
Thursday, June 28, 2018 5:09 PM
Hi folks,
My boss has tasked me with trying to get Always On VPN working to replace our Directaccess solution. I'd like to configure device tunnels using machine certs rather than user certs for a variety of reasons but am having cert difficulties, apparently.
First, the configuration:
1) Two-tier AD-integrated PKI running on server 2016. Machine certs for clients are being auto-enrolled after having duplicated and modified the computer template. Root and issuing CA certs are present on both client and server. Client and server certs use the RSA encryption algorithm, along with SHA256 signature and hash algorithms (problem?). The client cert contains the client and server auth EKU's. The server cert contains these, as well as the 'IP security IKE intermediate' EKU. CRL's are verifiable from the client on the internet. The Root and issuing CA's CRL's can be seen in the cache on server and client by running 'certutil -urlcache crl'.
2) The server uses the same name internally as externally, has RRAS and NPS cohosted and has its FQDN in the SAN and CN of the cert. RRAS is set to use Radius auth pointing the local NPS instance. This is tested working with a PSK L2TP VPN from my phone. 'Allow machine certificate authentication for IKEv2' is checked in the RRAS server's authentication methods.
3) A custom 'Always On VPN' Network policy has been created using 'Microsoft: smart card or other certificate' and 'Microsoft: Protected EAP (PEAP)' (not sure which to use), both configured with the server cert as authentication methods, and using a Windows group containing the Client computer as a condition:
4) I've downloaded and modified the sample ProfileXML file from Configure VPN Device Tunnels, then used the PS script available at the same URL to create the VPN object on the client using psexec as described here. The client is domain-joined Windows 10 Enterprise, build 1803.
The client repeatedly attempts to connect every 5-10 minutes, but each attempt terminates with an error 20227 from source RASClient:
Trying to manually initiate the connection from an admin command prompt with rasdial gives:
I've Googled the heck out of 13801 and 'IKE auth creds are unacceptable' to no avail. All hits point to problems with the server cert, such as the CN being inconsistent with the name used in the connection object, being expired, or having the incorrect EKU's. I'm not able to find much other guidance on creating device tunnels around.
Anybody got any ideas? I'm beginning to think this doesn't quite work yet... Thanks muchly,
ianc
All replies (7)
Friday, June 29, 2018 10:25 PM âś…Answered
OK, after another day of fiddling around, I finally cured it. Hopefully this will help someone else. If you have the 'Allow custom IPSEC policy for L2TP/IKEv2 connection' checkbox checked and a PSK entered on the RRAS server properties Security tab, the always on device tunnel client will not connect:
We're currently using L2TP PSK for Macs since obviously SSTP doesn't work for them and PPTP is crap. Finally in desperation I disabled it and bam, it just started working...
Another day, another $3.42...
ianc
Friday, June 29, 2018 1:12 AM | 1 vote
To start, the Always On VPN device tunnel does not use NPS. The authentication happens on the RRAS server and is not passed to NPS. The certificate on the VPN server must have the Server Authentication EKU and optionally (and recommended) to also include the IP security IKE intermediate EKU. The subject name on the certificate should be the public hostname that VPN clients use to connect to the VPN server (not the server's hostname). Also, you need to enable machine certificate authentication on the RRAS server. Here are some links that might be useful.
https://directaccess.richardhicks.com/2018/04/30/always-on-vpn-certificate-requirements-for-ikev2/
Hope that helps!
Friday, June 29, 2018 3:49 PM
Hi Richard,
"Hope that helps!"
Unfortunately it doesn't I'm afraid. I know my post is a bit long, but I tried to include all relevant details. If you read it, you'll see I have all the details you mention covered. I even reference one of your links in my post. ;)
Interesting factoid about machine cert auth being being processed by RRAS rather than NPS however, so I guess I don't need to worry about NPS any more.
Still not working though. Any more useful suggestions? Thanks,
ianc
Thursday, August 16, 2018 12:49 PM
IanC, I'm going through a similar experience with AlwaysOn right now. I was intrigued by your somewhat unorthodox method though. I was led to believe that computer certificate authentication didn't rely on NPS. In fact, if I turn off NPS on our system all the device tunnel users can still connect fine - which is to be expected.
But... you state that you have NPS running locally and additionally determining computer authentication based upon an AD security group as well? Does this work?
I'm very conscious that there is little access control when using device tunnels, other than revoking the certificate. If one can use an additional AD group to authenticate computer accounts then that would be perfect.
I'd love to know how you're getting on with that.
Regards,
Andy.
Thursday, August 16, 2018 3:44 PM
Hi Andy,
Initially I wasn't aware that NPS doesn't enter the equation if you have machine cert auth enabled on the RRAS server, but Richard Hick's post above cleared that up. Device tunnel auth via machine cert happens right on the RRAS server without the intervention of RADIUS, which is only used for user auth.
As for Always On VPN, I gave up on it. It's just not ready for prime time yet. I give it another year or so for them to get it working properly...
ianc
Friday, August 17, 2018 8:01 AM
Ian,
I do appreciate you taking the time to reply. It's a shame the scenario you portrayed above didn't work as expected.
I desperately want this product to work which is why I've been banging my head against the wall for the past two months trying to perfect it. It's so close, but not quite there. I'd love just to be able to use the Device Tunnel but am worried about the security aspect if the laptop fell into the wrong hands and I had no proper way to immediately deny access.
I'm hoping your prediction of another year is overly pessimistic.
Andy.
Tuesday, October 23, 2018 5:53 PM
Also, you need to enable machine certificate authentication on the RRAS server.
In my case, we are currently configured as a User Tunnel VPN, and we are testing Device Tunnel. The RRAS servers were not configured to allow machine certificates. This pointed me in the right direction. Thank you, Richard!