locked
Add DirectAccess at a later date RRS feed

  • Question

  • I am currently in the planning stages of implementing a 2 node UAG Array for ActiveSync\OA\OWA, OCS Reverse Proxy, and RDS RemoteApp.

    We have recently been asked to ensure that Direct Access Functionality can be enabled at a later date.  Is there any configuration tasks that I need to ensure are completed if this functionality will be added at a later date(Besides ensuring additional ports are opened up on front-end and back-end firewall)?

    Thank you very much in advance,

    Justin

    Thursday, May 6, 2010 1:25 AM

Answers

  • A few things to consider:

    * The UAG array members will need to be part of the domain. 

    * The UAG array member external interfaces will need to use public IP addresses and cannot be NAT'd. This likely means being placed direct on the external network or you will need to use a public IP addressed DMZ within your existing perimeter setup.

    * You will need at least four public IP addresses for a two node array; two DIPs and two VIPs. I would recommend you dedicate a 5th public IP address (or maybe more) for portal(s) use.

    * You will need appropriate protocols allowed through the FE and BE firewalls (as you said).

    This may be of use for more detail: http://technet.microsoft.com/en-us/library/dd857262.aspx

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by JCred101 Thursday, May 6, 2010 1:34 PM
    Thursday, May 6, 2010 8:40 AM
  • Agree with all of Jason's observations here.

    Also, you need to consider capacity planning too. The load introduced by DirectAccess can be significant, because we're doing IPsec and SSL/TLS encryption on the DirectAccess tunnels, and the traffic profile presented by DirectAccess can be significantly different than your reverse proxy deployment.

    We have some early capacity planning "information" (guidance is probably too strong a term) coming out very soon that will help you determine if you should use your reverse proxy array to support DirectAccess as well.

    RE: backend firewall configuration, we're currently recommending that you open it for all IPv4 and IPv6 traffic between the internal interface of the UAG DA server and the internal network. Then, you can analyze your network traffic profile and start locking things down. We found that many organizations don't really understand their intranet traffic profile, and since the DA client traffic profile will mirror the intranet traffic profile, your safest configuration is to allow all traffic from the UAG server to the intranet. The good news is that the TMG firewall is already on the UAG DA server, so the back-end firewall would represent a third firewall in the chain, which might be considered redundant in some scenarios.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    • Marked as answer by JCred101 Thursday, May 6, 2010 1:34 PM
    Thursday, May 6, 2010 1:21 PM

All replies

  • A few things to consider:

    * The UAG array members will need to be part of the domain. 

    * The UAG array member external interfaces will need to use public IP addresses and cannot be NAT'd. This likely means being placed direct on the external network or you will need to use a public IP addressed DMZ within your existing perimeter setup.

    * You will need at least four public IP addresses for a two node array; two DIPs and two VIPs. I would recommend you dedicate a 5th public IP address (or maybe more) for portal(s) use.

    * You will need appropriate protocols allowed through the FE and BE firewalls (as you said).

    This may be of use for more detail: http://technet.microsoft.com/en-us/library/dd857262.aspx

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by JCred101 Thursday, May 6, 2010 1:34 PM
    Thursday, May 6, 2010 8:40 AM
  • Agree with all of Jason's observations here.

    Also, you need to consider capacity planning too. The load introduced by DirectAccess can be significant, because we're doing IPsec and SSL/TLS encryption on the DirectAccess tunnels, and the traffic profile presented by DirectAccess can be significantly different than your reverse proxy deployment.

    We have some early capacity planning "information" (guidance is probably too strong a term) coming out very soon that will help you determine if you should use your reverse proxy array to support DirectAccess as well.

    RE: backend firewall configuration, we're currently recommending that you open it for all IPv4 and IPv6 traffic between the internal interface of the UAG DA server and the internal network. Then, you can analyze your network traffic profile and start locking things down. We found that many organizations don't really understand their intranet traffic profile, and since the DA client traffic profile will mirror the intranet traffic profile, your safest configuration is to allow all traffic from the UAG server to the intranet. The good news is that the TMG firewall is already on the UAG DA server, so the back-end firewall would represent a third firewall in the chain, which might be considered redundant in some scenarios.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    • Marked as answer by JCred101 Thursday, May 6, 2010 1:34 PM
    Thursday, May 6, 2010 1:21 PM
  • Yes I have seen the capacity planning information for the UAG with Direct Access.  I am assuming the plan will be to introduce a tool similar to the TMG Planning Tool?

    I will ensure to size appropriately, but the idea being is UAG Array will primarily be used as an inbound proxy\portal server initially.  Direct Access will be utilized in a pilot phase to show proof of concept to a select group.  Should it be deemed to be rolled out company wide, an additional node may need to be utilized.(although at this point we are talking about 300-400 users)

    If it were up to me, the internal NIC would be on the internal network for ease of configuration...but unfortunately this will more than likely not be the case.  Our Security team is not going to be very happy about opening all IPv4 and IPv6 traffic though.

    Thanks again Jason and Tom...you guys are machines!

    Thursday, May 6, 2010 1:41 PM
  • Good luck! :)
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, May 6, 2010 3:29 PM
  • Yes I have seen the capacity planning information for the UAG with Direct Access.  I am assuming the plan will be to introduce a tool similar to the TMG Planning Tool?

    I will ensure to size appropriately, but the idea being is UAG Array will primarily be used as an inbound proxy\portal server initially.  Direct Access will be utilized in a pilot phase to show proof of concept to a select group.  Should it be deemed to be rolled out company wide, an additional node may need to be utilized.(although at this point we are talking about 300-400 users)

    If it were up to me, the internal NIC would be on the internal network for ease of configuration...but unfortunately this will more than likely not be the case.  Our Security team is not going to be very happy about opening all IPv4 and IPv6 traffic though.

    Thanks again Jason and Tom...you guys are machines!


    It's been a week, do you have DA running yet? :-)

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, May 12, 2010 11:22 PM
  • Tom,

    I am finally getting around to getting the UAG array up and running. UAG installed and Array created...just waiting on the External IPs to come through and the FE Firewall to be configured so I can create the NLB Config.

    Many parties involved...so takes some time.

    Thanks though

    Friday, May 28, 2010 4:15 PM
  • Hi J,

    Great! Thanks for following up with us and looking forward to seeing it working great for you.

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Tuesday, June 1, 2010 3:16 PM