none
Always On VPN RRS feed

  • Question

  • Hi,

    If I use public certificate for SSTP connction, for any other reasons, does Always On VPN require CRL and OCSP of internal PKI to be available over internet for clients to establish VPN connection?

    Thanks

    Mahesh


    Mahi

    Thursday, October 31, 2019 8:00 PM

Answers

  • You won't have any issues issuing multiples certificates to the same user on multiple devices for Always On VPN for sure. However, I have no experience with EFS or Secure Email so I can't comment specifically on those scenarios.

    Richard M. Hicks
    Founder and Principal Consultant - Richard M. Hicks Consulting, Inc.
    directaccess.richardicks.com

    • Marked as answer by mahi Blr Saturday, November 9, 2019 8:00 PM
    Saturday, November 9, 2019 4:56 PM

All replies

  • No, not at all. Any certificate revocation checks will be performed by hosts/services already on your internal network. No need to publish CRL/OCSP publicly if you are using a public TLS certificate for SSTP.

    Richard M. Hicks
    Founder and Principal Consultant - Richard M. Hicks Consulting, Inc.
    directaccess.richardicks.com

    Thursday, October 31, 2019 10:38 PM
  • Thanks for taking your time to answer my question Richard!

    I have read your blogs on Always On VPN, its really helpful and gives lot of valuable information. I am so pleased to see your response!!!

    Would you be so kind to answer couple more questions;

    1.  Is it possible to use split tunneling and restrict VPN to specific applications with Always On VPN Device Tunnel?
    2. Are there any cons using TrafficFilterList (to make certain management servers accessible before user signin) with  Always On VPN Device Tunnel.
    3. What is the best practice for IP address assignment for VPN clients, using DHCP or Static address pool? 
    4. I did not find any MS documents on sizing RAS servers in terms on capacity. Any best practices around it?

    Thanks in advance!


    Mahi

    Friday, November 1, 2019 11:12 AM
  • My pleasure. :)

    Answers to your queries...

    1. Yes. You can restrict VPN use to specific applications, either by package name or executable path.

    2. There are several limitations that come with using traffic filters for Always On VPN. First, using a traffic filter prevents ALL inbound traffic to the client over the device tunnel. This prevents any manage out scenarios. Traffic filters also increase the management burden. It is up to you to define all required traffic, and if something changes you'll need to update the configuration to reflect that. This can be significantly challenging if you aren't using Intune, as you'll have to remove and redeploy all client VPN connections each time this is required.

    3. Best practice is to use static address pool assignments. Each VPN server should have it's own unique IPv4 subnet and/or IPv6 prefix. Internal network routes should return this traffic to each VPN server's interface accordingly.

    4. Microsoft has no formally published capacity planning guidance for Windows Server Routing and Remote Access Service (RRAS). The only reference I can find is this: https://blogs.technet.microsoft.com/rrasblog/2009/02/09/rras-performance-results/.

    Hope that helps!


    Richard M. Hicks
    Founder and Principal Consultant - Richard M. Hicks Consulting, Inc.
    directaccess.richardicks.com

    Friday, November 1, 2019 4:54 PM
  • Thank you again for your swift response!! Could you let me know your recommendation whether to setup Always On VPN with User Tunnel or Device Tunnel? Or use both? Which one is generally more beneficial in terms of features ? Currently we use Direct Access with split Tunneling (cloud applications traffic not routed over vpn).
    • Edited by mahi Blr Saturday, November 2, 2019 12:27 AM
    Friday, November 1, 2019 11:49 PM
  • My recommendation is to deploy the device tunnel only if absolutely necessary. If users must be able to logon without cached credentials (e.g. deploying new devices to remote users) or if you are using Azure self-service password reset for domain-joined devices, then deploy the device tunnel. Best practice is to limit access over the device tunnel to only those resources required to support domain authentication. You may also want to add PKI services (issuing CAs, CRL and OCSP servers) or systems management servers (WSUS, SCCM, etc.). 

    We typically don't recommend deploying the device tunnel for general corporate network access because it is not as strongly authenticated as the user tunnel. Device tunnel requires only a device certificate, where the user tunnel with EAP and client certificate authentication is much more robust and provides better assurance. It also supports integration with Azure MFA to further enhance the process.

    FYI, there's nothing that prevents you from deploying both device tunnel and user tunnel. I do that all the time. :)


    Richard M. Hicks
    Founder and Principal Consultant - Richard M. Hicks Consulting, Inc.
    directaccess.richardicks.com

    Saturday, November 2, 2019 6:56 PM
  • Thanks for the clarification!!

    One more question (more and more I dig in I got more and more questions..). With Always On VPN user tunnel, user can use non-domain joined machine to establish VPN connection. However, user tunnel requires user certificate to be present on the device before it can authenticate the user and establish secure VPN connection. How can I present internal CA issued user certificate on a device which is not joined to domain? Does this require additional configuration on the PKI platform ? or am I missing a point here.

    Your response would be greatly appreciated.

    Mahi

    Tuesday, November 5, 2019 4:47 PM
  • That's correct, you can deploy Always On VPN to non domain-joined devices. If you are using client certificate authentication (highly recommended) then you'll need to provision certificates using Intune. This will require you to implement a Network Device Enrollment Server (NDES) server on-premises and install the Intune certificate connector. Details here:

    https://docs.microsoft.com/en-us/intune/protect/certificates-scep-configure/

    Enjoy!


    Richard M. Hicks
    Founder and Principal Consultant - Richard M. Hicks Consulting, Inc.
    directaccess.richardicks.com

    Tuesday, November 5, 2019 6:37 PM
  • Hi,

    Just checking in to see if the information provided was helpful.

    Please let us know if you would like further assistance.

    Best Regards,

    Ellen


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.




    Friday, November 8, 2019 2:07 AM
  • Wah! thanks a lot. My apologizes for the delayed response.

    As users can establish VPN connection from BYOD devices, it can increase the number of user certificates issued to an user and vulnerabilities like stealing pvt. key on un-managed devices.  Would you be so kind to let me know;

    • What would be ideal validity period set for user certificate in this scenario. (So far we managed computer certificates but not user certificates).Kindly share if any best practices.
    • Default user certificate template can be used for AD user Authentication, EFS and Secure email exchange. Do you think we need to archive the pvt key of the user certificate by creating recovery agent before issuing the certificate for users? or Can I remove EFS and Secure Email from template? are these two, EFS and Secure email required for Always On VPN functionality?
    • Are there any vulnerabilities issuing user certificate issued from internal CA to BYOD device? are there possibilities to clean-up the certificate once VPN is disconnected? kindly share best practices.

    Mahi


    • Edited by mahi Blr Friday, November 8, 2019 3:18 PM
    Friday, November 8, 2019 3:10 PM
  • You should always take steps to protect private keys issued to mobile devices, no question. The best advice here is to ensure that the certificate is only issued to a device with a Trusted Platform Module (TPM). You'll see this option when you configure certificate deployment using Intune. The certificate lifetime is up to you, but they are commonly issued for one year. If you're uncomfortable with that you can always shorten the lifetime to meet your needs. The minimum requirement for the user certificate is Client Authentication, but yes, the default User template also includes EFS and Secure Email. I see no harm in including them, but you can remove them if you like. As for vulnerabilities, as long as you issue certificates only to TPM devices you should be ok. Make sure you revoke any certificates when users are deprovisioned of course.

    Richard M. Hicks
    Founder and Principal Consultant - Richard M. Hicks Consulting, Inc.
    directaccess.richardicks.com

    Saturday, November 9, 2019 12:11 AM
  • Thank you Richard for your prompt response!

    • Do we need worry about User certificates issued on multiple devices for the same user?meaning, each time user logs on to new device he gets new user certificate issued with a newer validity period. Will this not cause a problem managing private keys especially during key recovery or user deprovisioning period? Or is this the case that, all the certificates issued to a user will have same public/private key pair although having different validity period?

    • Is it normal practice to prepare user certificate for key archival and setup key recovery agent before it is issued to end users with EFS and Secure Email options? Just avoid users coming back in later stage encryptions related issues when private key is lost?

    • When User certificate is expired due to some reason or CA server certificate is renewed with new key pair will that affect files encrypted with EFS? Meaning users will have issues decrypting?
    • Edited by mahi Blr Saturday, November 9, 2019 8:14 AM
    Saturday, November 9, 2019 8:10 AM
  • You won't have any issues issuing multiples certificates to the same user on multiple devices for Always On VPN for sure. However, I have no experience with EFS or Secure Email so I can't comment specifically on those scenarios.

    Richard M. Hicks
    Founder and Principal Consultant - Richard M. Hicks Consulting, Inc.
    directaccess.richardicks.com

    • Marked as answer by mahi Blr Saturday, November 9, 2019 8:00 PM
    Saturday, November 9, 2019 4:56 PM
  • Hi Richard,

    Would you be so kind to help me on this query?

    I am testing Always On VPN; in my test environment have 2 RAS servers clustered with Windows Network Load Balancer Manager and two windows 10 client machines to test the connection and load balancing.  What I notice is that NLB is not load balancing the connections between two servers, rather it is working in kind of failover mode, client connects successfully to another RAS if either one of the server in NLB is down. Both RAS servers are in the same VLAN. Question is, how do I load balance the VPN connections evenly between RAS servers using Windows NLB? we also have Citrix Netscaler, and Fortinet firewall, are those can be used to load balance RAS (IKEv2) servers?


    Mahi

    Tuesday, November 19, 2019 10:38 AM
  • If your test clients are behind a NAT, that could explain it. I see this quite commonly, in fact. When clients are behind a NAT, NLB (or any load balancer) sees the connections coming from the same source IP address and sends them to the same back end server. It's a good idea to make sure the RRAS VPN servers can see the real source IP address of the client, if possible. This has other positive benefits too.

    For the record, I'm not a big fan of NLB and I always recommend using a proper load balancing appliance. Using the NetScaler would be a much better idea if you have access to that, IMO. 😁


    Richard M. Hicks
    Founder and Principal Consultant - Richard M. Hicks Consulting, Inc.
    directaccess.richardicks.com

    Tuesday, November 19, 2019 1:48 PM
  • Thanks you for your quick response.

    Test clients are not behind the NAT device. Those are in the same VLAN of external interface of RAS server. Environment built as per microsoft test lab setup guide (https://www.microsoft.com/en-us/download/confirmation.aspx?id=39638)

    Is this issue only with Windows NLB or with any other NLB solutions as well like KEMP?

    In production environment, most of the devices will be behind NAT device, could you advise how to overcome this?


    Mahi

    Tuesday, November 19, 2019 6:55 PM
  • If your test clients aren't behind a NAT, then it could be something to do with the NLB configuration. As I don't use NLB I can't really offer any guidance for troubleshooting that unfortunately.

    The issue I described above with clients behind a NAT would apply to external load balancers like the Kemp LoadMaster and any other appliance. To ensure the load balancer sees the client's real IP address, you can either put the public IP address on the load balancer (not recommended) or when the load balancer is behind an edge firewall configure a destination NAT (DNAT) only. Avoid translating the client's source IP address whenever possible.


    Richard M. Hicks
    Founder and Principal Consultant - Richard M. Hicks Consulting, Inc.
    directaccess.richardicks.com

    Tuesday, November 19, 2019 7:44 PM
  • Ok, thank you Richard.

    Mahi

    Tuesday, November 26, 2019 4:48 PM