locked
DA not working with client firewall profiles enabled RRS feed

  • Question

  • I've been trying to get DirectAccess working for quite some time now without success.

    I've discovered that if i disable the windows private networks firewall profile on the client computer that i am able to connect to DA and ping internal corporate servers.  I've enabled logging of dropped packets on the client windows firewall and i see dropped UDP 53 packets.  So i've created an outbound rule to allow udp 53 and its still logged as dropped.   I've also allowed all outbound and i'm still unable to connect.  If i disable the windows private firewall profile on the client, DA connects immediately.

    The DA server is setup as basic as it can be, with a single nic and self-signed certs.  The corporate firewall is allowing internal 443.  We have a GPO that disables the "domain networks" firewall profile otherwise defaults plus the changes made by the DA getting started wizard GPOs

    Any help would be greatly appreciated!!

    Edit:  Server Currently Server 2016.  I've tried multiple deployments of 2012.  Client is Windows 10 1607 enterprise


    • Edited by jharrell1 Tuesday, November 28, 2017 4:14 PM
    Tuesday, November 28, 2017 4:09 PM

Answers

  • The fix for me was to enable all firewall profiles on the DA server.
    • Marked as answer by jharrell1 Thursday, December 7, 2017 4:13 PM
    Thursday, December 7, 2017 4:13 PM

All replies

  • Given your datapoint that disabling the Private profile fixes it, it obviously makes me think that some rule that applies itself only to the Private profile must be blocking something. When you disable Private, I assume your client then flips over and starts using the Public profile? The DA rules themselves (Connection Security Rules) are designed to be enabled/connecting anytime that either Private or Public is active inside the client's WFAS. So DA connects in either of those circumstances, but never when the Domain profile is active (so that DA doesn't try to connect tunnels from inside the corp network)

    In situations like these it is sometimes helpful to try bringing a client online without any of your existing GPOs applied. Put a laptop in an OU with inherency blocked so that it doesn't get policies, and then manually link just the DA client settings, then test it out. If it works properly, then you know that it is something inside one of your existing policies that is causing this issue, and it can be tracked down from there.

    And then more general feedback on DA for you - when you are ready to go production with this I would definitely recommend re-visiting your implementation of the DA server. Dual NIC mode generally behaves better than single NIC, and you should definitely get away from using self-signed certs. That can cause a lot of problems on its own accord.

    Thursday, December 7, 2017 1:28 PM
  • The fix for me was to enable all firewall profiles on the DA server.
    • Marked as answer by jharrell1 Thursday, December 7, 2017 4:13 PM
    Thursday, December 7, 2017 4:13 PM