none
Always-ON VPN User Tunnel cannot contact a domain controller RRS feed

  • שאלה

  • Using nslookup I see that the correct DNS server (also the DC) is selected.

    The NIC has register DNS suffix off and the VPN connection has it turned on.

    I have flushed and re-registered dns.

    I am able to lookup the FQDN of the domain "domain.com" and get the single domain controller's IP address.

    I can resolve hostnames and FQDNs of other computers and servers on the domain, i.e (SRV01.domain.com and SRV01)

    However, when attempting to access file shares with the host name without the suffix, I am met with a message stating that I cannot contact the domain controller, and typing in credentials then allows access to that folder.

    This also seems to apply to things like Enter-PSSession, giving a WinRM unknown security error without the domain suffix.

    It also fails to read certain group policies while on the user vpn profile.

    Disabling the User Tunnel and solely using the Device Tunnel seems to resolve all of these issues, but this is not feasible as I am unable to use the Always-On functionality without Enterprise Windows.

    Any information about this would be appreciated. Thanks.

    יום שני 08 יולי 2019 20:59

תשובות

  • I think figured it out.

    I had improperly decommissioned my previous CA, (deleted the VM without thinking about it). When I ended up recreating the CA with the same name, I guess an old root certificate was still floating around the domain (deleting it from computers manually didn't seem to fix it).

    After properly decommissioning it this time and recreating the infrastructure again, the old certificate did not appear. After making the necessary changes regarding certificates in VPN profiles, it seems that the issue has been solved.

    Thanks so much for your time.

    • סומן כתשובה על-ידי wsanders_ יום שני 15 יולי 2019 20:26
    יום שני 15 יולי 2019 20:26

כל התגובות

  • Hi,

    I would suggest you check the DNS elements in the profile XML. 

    <DomainNameInformation>
    <DomainName>.corp.contoso.com</DomainName>
    <DnsServers>10.10.1.10,10.10.1.50</DnsServers>
    </DomainNameInformation>

    <DnsSuffix>corp.contoso.com</DnsSuffix> 

    Please refer to the link below:

    https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections 

    Best regards,

    Travis


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

    יום שלישי 09 יולי 2019 02:47
    מנחה דיון
  • The profile XML has all of these elements present. The only difference I can spot between my VPN profile and the one discussed on the client configuration page is that I opted to use force tunneling instead of split tunneling.

    יום שלישי 09 יולי 2019 21:25
  • If you are using client certificate authentication you will need to make sure your DCs have a certificate issued by your internal PKI. More details here:

    https://directaccess.richardhicks.com/2019/05/28/always-on-vpn-users-prompted-for-certificate/


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

    יום רביעי 10 יולי 2019 00:57
  • Certificate selection is configured like the method mentioned in your article, for my network certificate purpose is not a problem.

    However, I was not having any issues with the VPN connection automatically connecting.

    After looking at the additional information links, I found this article to be more relevant

    https://directaccess.richardhicks.com/2019/05/20/always-on-vpn-clients-prompted-for-authentication-when-accessing-internal-resources/

    However, I already have a domain controller authentication certificate that meets the requirements for client auth, server auth, and smart card logon.

    I still have the same error regarding the failure to contact a domain controller.

    יום שני 15 יולי 2019 00:46
  • Hi,

    I understand your frustrations.

    I believe that troubleshoot the issue requires some hands on access. 

    My suggestion is to contact Microsoft Support to get them involved in checking your configuration.

    Best regards,

    Travis


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

    יום שני 15 יולי 2019 08:18
    מנחה דיון
  • I think figured it out.

    I had improperly decommissioned my previous CA, (deleted the VM without thinking about it). When I ended up recreating the CA with the same name, I guess an old root certificate was still floating around the domain (deleting it from computers manually didn't seem to fix it).

    After properly decommissioning it this time and recreating the infrastructure again, the old certificate did not appear. After making the necessary changes regarding certificates in VPN profiles, it seems that the issue has been solved.

    Thanks so much for your time.

    • סומן כתשובה על-ידי wsanders_ יום שני 15 יולי 2019 20:26
    יום שני 15 יולי 2019 20:26
  • Hi,

    Good to hear that you have solved this issue by yourself. In addition, thanks for sharing your solution in the forum as it would be helpful to anyone who encounters similar issues.

    If there is anything else we can do for you, please feel free to post in the forum.

    Best regards,

    Travis


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

    יום שלישי 16 יולי 2019 05:59
    מנחה דיון