none
DirectAccess Client not connecting without error code on Windows Server 2012 R2 and Windows 8.1

    Question

  • Hello,

    we are currently migrating from Windows Server 2012 to 2012 R2 and are not able to get the new Direct Access Service up and running. Our goal is to establish DirectAccess connection for a handful of clients using the IPHTTPS-adapter on the default port 443.

    Errors:
    There is actually no error showing up. It seems the infrastructure tunnel cannot be created but none of the IPv6-transition adapters is connecting (teredo and 6-to-4 are down) and the IPHTTPs adapter gives no informations about a problem:

    >Get-DAConnectionStatus

    Status    : Error
    Substatus : CouldNotContactDirectAccessServer

    >Get-NetIPHttpsState

    LastErrorCode   : 0x0
    InterfaceStatus : Failed to connect to the IPHTTPS server; waiting to reconnect

    Setup:
    Our setup is a virtualized Windows Server 2012 R2 Standard running on Hyper-V. It is located behind a NAT having the Port 443 mapped to the server. The only role installed after the basic install is RRAS including DirectAccess and VPN. The assistants completed successfully (running the configuration for DirectAccess and VPN). Operation Status says everything is green und working (for multiple days in the meanwhile). A previous direct access installation (on a different machine running Windows Server 2012) has been removed before installing the new server. The new installation is using a different router, so this might also be the cause of a problem.

    The client is a Windows 8.1 notebook located outside the company network accessing the internet through another NAT-device. The client has been able to connect to the previous DirectAccess setup but has never been able to establish a connection after the setup of the new Direct Access server. The device has no outbound constraints concerning the NAT-device and is only running the integrated Windows Firewall.

    Diagnosis:
    So far I've done some basic DNS and connectivity checks. The DNS-name can be resolved correctly and the router even responds to pings. The port forward is working and HTTPs connections are generally possible (temporarily routed the port to access the NLS-Website located on the server, which worked fine).

    Network monitor shows that both computers are communicating, traffic on the expected Port 443 is incoming on the server and responses from the server reach the client.

    Opening the IPHTTPs-url and in an endless page load. Sometime the browser page closes but I've never seen any result. Using telnet on the port shows that the server is accepting connections. I've even build a small test application that does a GET-Request on the URL returning HTTP-200 and no content.

    I'm currently running out of ideas what to do and since no error occurs this is kind of a bit frustrating. Any help appreciated.

    Regards
    Matthias

    Saturday, December 21, 2013 6:30 PM

Answers

  • Alright. Seems I finally found the issue. The DirectAccess GPOs got unlinked from the domain. Not sure how this happened and I only discovered it once I used a different client than the local system to connect with the "Remote Access Management Console". This gave me the error "Configuration for server [server name] not retrieved from the domain controller. The GPO is not linked." (http://technet.microsoft.com/en-us/library/jj574221.aspx) Strangely it does not display any error on the local systems console. I also would have expected to notice the problem on the test-clients, but I guess they somehow got the configuration (since they do have the correct configuration) before the unlinking happened.

    To fix the issue I simply linked the GPOs to the domain root again. After refreshing the GPOs on the DA-server all clients seem to connect fine.

    Thanks for your help anyway.

    Tuesday, January 07, 2014 10:21 AM
  • Unfortunately the 0x4c9 error was not resolved by fixing the GPO. After a few days, the problem returned and took us over a month to track it down. We ultimately found the issue in our client protection software, namely "Kaspersky Anti-Virus 2014" (not "Kaspersky Internet-Security", which seems to cause the same problem by the way). After uninstalling, the problem went away and DirectAccess is working since then.

    In the Kaspersky forums are a few threads that discuss the topic and some have successfully changed the KAV-configuration to get DirectAccess working. An exempt for svchost.exe seems to unblock the connection. Haven't tested this since we decided to change the client protection software, but maybe this helps someone.

    Friday, February 28, 2014 8:44 AM

All replies

  • can you generate the full set of logs from your windows 8.1 client please and post them.

    also the setup you are using - is it just windows 8 enabled - ie no windows 7 support, and the certificates used are they public or private?

    if you put another client that is currently on your LAN does it detect it is on the LAN and doesn't try and connect through DA?


    Regards,

    Denis Cooper

    MCITP EA - MCT

    Help keep the forums tidy, if this has helped please mark it as an answer

    My Blog

    LinkedIn:

    Monday, December 23, 2013 8:18 AM
  • Our setup is not Windows 7 enabled. Every DNS-option is set to the least restrictive. We use private certificates that are generated from a key chain that is trusted on both server and client (certificate is shown as "valid" on both systems). The same certificates have been used by the previous installation.

    Generated the DirectAccess Logs but since it contains a lot informations about our productive system, I'm not willing to post it in full. I can send you in private or maybe you can specify the logs you need.

    Could not yet test a client within the LAN. VPN is also deployed with the RRAS-server and is working fine (so at least basic routing does work). Once connected over VPN the client stops trying to connect on DirectAccess.

    Currently the error code on the client switched to 0x4c9.

    Monday, December 23, 2013 7:45 PM
  • Ok. Will have a look for you and see what the useful parts of the logs show. Can you just reconfim that everything is green in the remote access console. And also take a look on the windows firewall and make sure all the settings for the new server only.

    Regards,

    Denis Cooper

    MCITP EA - MCT

    Help keep the forums tidy, if this has helped please mark it as an answer

    My Blog

    LinkedIn:

    Monday, December 23, 2013 8:53 PM
  • I confirm that the operation status show "working" for all items.

    The Firewall rule "Core Networking - IPHTTPS (Tcp-In)" is active for all profiles. Current profile is the domain profile. The firewall log shows no packet drops. The connection security rules are also configured, but I guess that's not of primary interest since the infrastructure tunnel is failing before any IPSec can take place.

    Tuesday, December 24, 2013 10:33 AM
  • are you able to monitor the firewall and see any connection attempts?

    have you tried on any other computer?

    it sounds like some setting is not applying to the computer correctly


    Regards,

    Denis Cooper

    MCITP EA - MCT

    Help keep the forums tidy, if this has helped please mark it as an answer

    My Blog

    LinkedIn:

    Tuesday, December 24, 2013 10:58 AM
  • Enabled full firewall logging. Again no packet drops and connections to 443 are logged as permitted:

    2013-12-24 12:47:49 ALLOW TCP [External Client IP] [Internal Server IP] 52094 443 0 - 0 0 0 - - - RECEIVE
    2013-12-24 12:47:49 ALLOW TCP [External Client IP] [Internal Server IP] 52093 443 0 - 0 0 0 - - - RECEIVE

    As stated in my initial post, I analyzed the network connections using Microsofts Network Monitor. IP-connections are established in both ways (the client sends and receives from the server).

    I tried another Windows 8.0-client which resulted in the same problem.

    Tuesday, December 24, 2013 11:51 AM
  • just as a thought, I've seen it where direct access thinks its not connected and says trying to connect, but actually is connected, have you checked to see if you can ping / access any resources?

    Regards,

    Denis Cooper

    MCITP EA - MCT

    Help keep the forums tidy, if this has helped please mark it as an answer

    My Blog

    LinkedIn:

    Tuesday, December 24, 2013 11:55 AM
  • Hi,

    In addition, have you disabled the DA client components on the DA client? If no, please also check the settings on the Name Resolution Policy Table.

    More information:

    DirectAccess Client Location Awareness – NRPT Name Resolution

    In addition, error 0x4C9 means the remote computer refused the network connection. It may be due to the invalid registry or corrupt drivers. For more detailed information, please refer to the link below:

    Error 1225 - Error Code 0x4C9

    Note: Microsoft is providing this information as a convenience to you. Please make sure that you completely understand the risk before retrieving any suggestions from the above link.

    Best regards,

    Susie

    Wednesday, December 25, 2013 9:23 AM
    Moderator
  • The IPHTTPs-adapter show the state "disconnected" and hence has no IP-address. Attempting to reach or ping any internal resource already fails with DNS resolution errors. Also checked the other adapters on the client. None of them shares a network with the server, nor has any of them the configured network prefix of  the DA-service (Corp-prefix with 1000).
    Wednesday, December 25, 2013 3:22 PM
  • Hi Susie,

    I did not explicitly disable the DA client components. I'm pretty sure they are enabled, at least they were working with the other DA-server and I didn't take any measures to disable them. Except for the changed DA-Policy there are no changes to the client system. Tried another client (which was also connected to the previous DA-setup) having the same error.

    The NRPT-policy on the client shows our domain name configured with the DA-Servers IPs. There are only two exempts: one for the NLS-server and one for the external name of the DA-Server.

    I have the suspicion that the routing or the new server do have issues, but I have no clue what it might be and how I can narrow down the possibilities.

    Wednesday, December 25, 2013 5:16 PM
  • Alright. Seems I finally found the issue. The DirectAccess GPOs got unlinked from the domain. Not sure how this happened and I only discovered it once I used a different client than the local system to connect with the "Remote Access Management Console". This gave me the error "Configuration for server [server name] not retrieved from the domain controller. The GPO is not linked." (http://technet.microsoft.com/en-us/library/jj574221.aspx) Strangely it does not display any error on the local systems console. I also would have expected to notice the problem on the test-clients, but I guess they somehow got the configuration (since they do have the correct configuration) before the unlinking happened.

    To fix the issue I simply linked the GPOs to the domain root again. After refreshing the GPOs on the DA-server all clients seem to connect fine.

    Thanks for your help anyway.

    Tuesday, January 07, 2014 10:21 AM
  • Hi,

    Good to hear that and thanks for your share.

    Have a good time!

    Best regards,

    Susie

    Thursday, January 16, 2014 5:53 AM
    Moderator
  • Unfortunately the 0x4c9 error was not resolved by fixing the GPO. After a few days, the problem returned and took us over a month to track it down. We ultimately found the issue in our client protection software, namely "Kaspersky Anti-Virus 2014" (not "Kaspersky Internet-Security", which seems to cause the same problem by the way). After uninstalling, the problem went away and DirectAccess is working since then.

    In the Kaspersky forums are a few threads that discuss the topic and some have successfully changed the KAV-configuration to get DirectAccess working. An exempt for svchost.exe seems to unblock the connection. Haven't tested this since we decided to change the client protection software, but maybe this helps someone.

    Friday, February 28, 2014 8:44 AM