locked
Direct Access UAG 2010 with back firewall RRS feed

  • Question

  • Guys,

    We are doing a deployment of Direct Access and were receiving significant challenges from the firewall team to our request for an ANY-ANY internal firewall rule from the DA servers to the internal network.

    All of the documentation I can find on this states the firewall should be configured in this way and as a result I am facing delays in deployment.

    Can anyone advise of any official documentation that relates to this configuration or offer up any advise how I can address their concerns?

    Thanks

    Friday, November 2, 2012 4:36 PM

All replies

  • It is a remote access gateway and consequently, just like a VPN concentrator, needs pretty open access to corporate resources if you want it to provide corporate remote access. If you currently use VPN you may be able to argue that the DA server is similar to the VPN terminator for other solutions. To mitigate the risk, you can add NAP and 2FA/OTP authentication to increase the security of establishing the remote access tunnels, but ultimately the gateway still needs access to corporate resources like any other remote access gateway.

    In theory, there is nothing stopping you from building a firewall policy that defines protocols and destinations to limit connectivity to specific allowed internal hosts, but this will no doubt take quite a bit of time and effort and also become an admin overhead as the corporate environment changes. You dont have to have an open policy, but it makes sense if you think about the concept of DirectAccess being an extention of the corporate network... 

    I assume UAG is being deployed in your perimeter network?

    Cheers

    JJ


    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Monday, November 5, 2012 12:07 PM
  • I have customers running backend firewalls in this scenario, but most of them encountered some struggles along the way. There can be no definitive list of what needs to be opened, as every environment is different. Even simple infrastructure items like AD communications can be running on many different ports.

    Because there is no possible way to create a list, it must be the recommendation to allow everything. When this presents a problem for me, I typically handle it by suggesting that we start by opening everything, and once we confirm that DirectAccess is working, then we can start "tightening the belt", locking things down methodically, making sure to test in between each change. This is a long, slow process, but it works and sometimes it's the only way to make DA pass written security policy.

    Monday, November 5, 2012 4:54 PM