Direct Access-Win2016 Server to Win 10 Ent client - "Connecting" and "CouldNotContactDirectAccessServer" RRS feed

  • Question

  • Hi,

    i have been trying to create a directaccess connection in a lab. 

    I have a Windows 2012 R2 domain controller, and have deployed a new Windows 2016 Server for this Directaccess lab.

    The directaccess server is a domain member and i have installed DriectAccess and configured it using the wizard using one Nic. all the config looks good. and the server setup is healthy, the dashboard show all green ticks. 

    The server's ip address is accessible from the internet by port forwarding port 443. i have defined an internet resolvable DNS name that points at my server which was used in the wizard.

    Group policy's look fine. i've created a security group and added the computer account of the client into it.

    Connected to the internal network i have pushed the policy to the client (gpupdate) and can confirm it has the policy (gpresult).

    When connected internally, all works as it should. The get-daConnectionStatus command shows "ConnectedLocally". all looks fine.

    However, when i disconnect and connect to the internet externally, my clients all just sit there and do not connect. get-daconnectionstatus shows "CouldNotContactDirectAccessServer". It never actually connects or gives me any real error as to what is going wrong. It doesn't tell me much more than that. Clearly that error means something.....but what?

    i have verified correct internet DNS settings. i can use EDGE on win10 client to navigate to and i cannot see much except i can see the self signed certificate that is from the server. so, that suggest DNS, routing etc. is all working. and group policy etc.

    I cannot work out what is failing. 

    And.....this is my third attempt. So whatever i am doing wrong it is systemic. i have already "nuke'd" the entire lab and rebuilt it twice because i just cannot get this DirectAccess working. The aim is evaluate directaccess for possible deployment at work in the future. but i just cannot get it to work.

    i see some people suggest that a one NIC setup is troublesome. And i would try a two-NIC DMZ approach but i do not have that capability in my lab (home lab).

    Any suggestions? 



    Wednesday, August 8, 2018 12:18 PM

All replies

  • You are definitely right that single-NIC implementation can be problematic, but it is possible. Down the road in your production environment, definitely shoot for dual-NIC.

    The second red flag I see in your description is the self-signed certificates. The ability to do DA with self-signed certs is something that never should have been added in my opinion, because some people get it working this way and then leave it working that way, and it's a terrible thing from a security perspective. Much better would be to get a real SSL certificate, even for your lab (there are public CAs that will issue trial certificates that could give you 30-90 days of free use)

    If you're using the Getting Started Wizard for deploying DA, then it's also cutting other corners that you haven't mentioned yet. Namely you are probably deploying without an internal CA and therefore without machine certificates being part of the authentication chain, which again might be okay for POC but should not be the case for production rollout.

    All in all, it's usually best to deploy a POC with the best practices in place, because then it actually mirrors what you are looking at for production. I have worked with numerous cases where an installation based on the Getting Started Wizard was having weird problems, and recreating that environment in the right way resolved all of those problems. So I'm afraid continuing to set it up in a limited fashion will always be causing you hindrances of one kind or another.

    Thursday, August 23, 2018 2:55 PM
  • Jordan,

    Thank you for your comments.

    You make some good points. And I guess i certainly wasn't expecting a great result from my lab. Not as far as security and performance goes. But, i was expecting it to work. 

    Unfortunately, i was hoping to get a bit of a result, familiarise myself with the technology and it's function and then actively promote the solution to my colleagues at my workplace. But i can hardly do that now. if i cannot get it to work after multiple attempts, following the docs as given, i am sure as heck not going to suggest we do all this again at work. 

    As you point out, the compromises i have made in my lab may actually be causing me issues. But it also highlights how difficult DirectAccess is to troubleshoot and correct issues. it looked to be much improved...but.

    i will be interested to see what future holds for DircetAccess. 

    i think i will stop butting my head against a wall and give up on it.



    Friday, September 21, 2018 1:05 PM