UAG DirectAccess: Firewall and DNS Considerations

Author by Shannon Fritz

UPDATE: My guide for Configuring DirectAccess with UAG Service Pack 1 has been released! Read it here.
Generally speaking, people typically will not connect a Windows server directly to the Internet with it's own public IP.  The Windows Firewall by itself, as good as it is, often times does not muster up a lot of confidence in Network Administrators.  Instead, a device or hardware firewall is generally placed between the servers and the public internet to filter traffic based on any number of rules that allows or denies connections in and out of the corpnet. This is where a DMZ or "Demilitarized Zone" comes in to play.  Placing a UAG DirectAccess server behind a firewall is 100% supported, but there are some things you must do to the perimeter (aka "front-end") firewall to allow DirectAccess to function. Tom Shinder has a great blog post on this subject which also covers other deployment scenarios.

Perimeter Firewall Rules

In general I have found the following rules need to be configured on the External firewall to allow inbound traffic for both of your UAG servers External IP's:
  • Allow inbound and outbound "Protocol 41" (aka ISATAP) to support 6TO4 connections.
  • Allow UDP trafic over port 3544 to support Teredo connections.
  • Allow TCP traffic over port 443 to support IP-HTTPS connections.
  • Allow ping (ICMP echo).
Of course how you impliment these changes will vary and depend greatly on the make and model of your firewall, so that is a task I will leave up to you to explore.

UAG/TMG Firewall Rules

The UAG server has the Threat Managment Gateway (TMG) service built in.  While you can use it as a normal TMG, it's purose is really to be just a more robust firewall for the UAG compared to what comes with Windows.  However this also means it comes out of the box with just about everything blocked including PING, Remote Desktop and File Sharing.  So I like to add a couple of my own rules to enable a few thing on the Inside interface. Keep in mind most of these rules are not required to get DirectAccess to work!  They just make administration of the UAG server easier (IMO). [caption id="attachment_1303" align="alignnone" width="300" caption="Custom rules added to TMG on the UAG server."][/caption] I should also point out that adding custom rules to TMG on a UAG server is not something that the support staff at Microsoft will find particularly awesome.  It is supported, but it falls into a kind of grey area because if you have added your own rules, there is potential for you to override a rule that UAG creates, and that can cause complications in diagnosing problems.  For that reason, I would not make any changes that affect the External interface, except for one thing: PING.  If you cannot ping the external interface of the UAG server then DirectAccess will not work, so let's start there. To add a custom rule, open the Forefront TMG console (not UAG) and select "Firewall Policy" on the left.  Scroll down to the bottom and highlight the "Last" rule.  Now right click "Firewall Policy" from the left side and select "New" > "Access Rule". This will start a wizard where you can Name and Define the new rule.  Let's call this one "PING", click next and set the action to "Allow".  For "Selected Protocols" click Add, expand "Infrastructure" and select PING.  Click Add.  Scroll down, expand "IPv6 Infrastructure" and select "ICMPv6 Echo".  Click Add, Close and then Next.  For the Sources click Add, expand Networks and add External and Internal.  Click Close, then Next.  For Destination click Add, expand Networks and add Local Host.  Click Close and then Next.  Leave the default "All Users" in for User Sets and click Next.  Review the summary and click Finish and then Apply the changes. [caption id="attachment_1309" align="alignnone" width="300" caption="Steps to allow IPv4 & IPv6 PING from inside and out."][/caption] Now you should be able to PING the UAG server from the Intranet and from the Internet as well.  Just keep in mind that, for that particular rule, if the UAG server is behind a firewall you will need allow ping to both IP's through that firewall as well. Here are some other rules I like to Allow: File Shares, Inside Only (This allows you to access uagserverc$ and any other file shares you might create) * Protocols: Microsoft CIFS (UDP), Microsoft CIFS (TCP) * Sources: Internal, Local Host * Destination: Internal, Local Host RPC, Inside Only (Allows opening MMC's from other servers inside) * Protocols: RPC (all Interfaces), RPC Server (all interfaces) * Sources: Internal, Local Host * Destination: Internal, Local Host Remote Desktop, Inside Only (Allows RDP from inside) * Protocols: RDP (Terminal Services) * Sources: Internal * Destination: Local Host When you're all done don't forget to Apply the changes, otherwise your settings will not take effect. Once you hit Apply it seems to take a minute or two before the changes actually take place.

About DNS and DirectAccess

When you have an IPv4 network behind a UAG server, DirectAccess clients are completly dependent on DNS to function, especially when you have IPv4 behind the UAG server.  In these cases UAG acts as an ISATAP router which turns IPv6 into IPv4 and IPv4 into IPv6.  To do this it uses magic!  Or, maybe it's NAT64 and DNS64.  Sometimes it is hard to tell.   Here is a TechNet article on those two technologies, and here is a blog post with pretty pictures on how it works. Essentailly, when an application tries to send traffic to a host name, the route it takes to reach that host name is determined by it's DNS name.  If the applications uses an IP address instead of a host name it'll never use the DirectAccess virtual interfaces and instead route over the normal interface to the network immediatly available to the machine.  The majority applications will simply work over DirectAccess when they use hostnames to establish their connections, however there are some exceptions. For example, when using ping.exe from a DirectAccess client, it can reach anything in the corpnet that'll respond to a ping, however nslookup.exe will not return any results for those very same host names that you can ping.  Why?  Because nslookup does not use the Name Resolution Policy Table (NRPT) and by default works with IPv4.  The request simply never traverses any of the DirectAccess interfaces to it reaches the corpnet to do the lookup.  To use nslookup on a DirectAccess client to find addresses of machines behind a UAG server you must tell it to ask for an IPv6 address from the IPv6 address of your DNS server.  It's a bit convoluted: nslookup -q=aaaa [hostname] [dnsipv6address].  For that reason, I generally avoid using nslookup as a part of any diagnostics with DirectAccess clients.  Becides, if you try to ping a host name it'll tell you what IP it's using, be it IPv4 or IPv6. Here are couple things you need to be aware of specifically related to DNS.

External DNS

You should make sure you create the necessary A-record in your external DNS to point to the first external IP address.  Something like UAG.domain.com or DirectAccess.domain.com works pretty well but you can just as easily use the UAG server hostname.  Keep in mind no one will ever see or decidedly use this hostname, so it's really pretty irrelevant what it is and there's no need to make it "pretty" or user friendly. I mentioned earlier that DirectAccess clients can connect via one of three methods: 6TO4, Terreo and IP-HTTPS.  To support IP-HTTPS connections DirectAccess encapsulates it's traffic within HTTPS packets.  This will require a web certificate and therfore a hostname to register the certificate to.  This certificate does not need to be issued from a third party certificate authority like VeriSign or Thawte because only domain members will be connecting to this HTTP service.  So you can use a certificate issued from your own Enterprise CA since they will already be trusted by these domain member computers.

Internal DNS

Domain Name Services in a Windows Domain allows clients to dynamically update their DNS records.  While this is pretty great, it also presents an opportunity for malicious users to try manipulating DNS records in an effort to divert trafic that is destined for a particular hostname to instead arrive someplace that it should not be going (aka "DNS Hijacking").  To mitigate some of this risk, the Windows Server 2008 DNS role uses what's called a  "Global Query Block List" that prevents some of the more vulnerable protocols from being serviced by DNS requests, specifically WPAD and ISATAP.  That second one is essentailly is what allows DirectAccess clients to tunnel through the UAG server, so you need to remove ISATAP from the block list in order for DirectAccess to work. Before making changes, I like to know what the current settings are.  Open an administrative command prompt on one of your 2008 DNS servers and run this command: [caption id="attachment_1473" align="alignnone" width="347" caption="dnscmd /info /globalqueryblocklist"][/caption] This will show you the current items on the blocklist.  Generally you should only see two things: wpad and isatap.  There is no way to just remove an item from this list, instead you have to reset it to the values you want, so take a look at what's in there and then run this next command to set the new list: [caption id="attachment_1474" align="alignnone" width="347" caption="dnscmd /config /globalqueryblocklist wpad"][/caption] Now when clinets do a DNS lookup for ISATAP the servers will actually return an answer!  BTW, if you had more items in your block list just append them to the command seperated with spaces.  For example, if you were blocking "wpad", isatap" and "foo", you would run "dnscmd /config /globalqueryblocklist wpad foo" to continue blocking everything except for isatap. This TechNet article shows that you can also effect those changes by updating the registry, but I find the dnscmd utility to be a bit more straight forward, especially since you need to open an elevated command prompt anyway to restart the DNS Service. Later on, the configuration wizard will create the ISATAP DNS record for you.
Next Step:
Index 1. IP Addressing the UAG Server 2. Unified Access Gateway Installation & Updates 3. Firewall and DNS Considerations 4. Certificates, Groups and Client Requirements 5. Configure other Prerequisites for UAG 6. Configuration Wizard: Clients 7. Configuration Wizard: DirectAccess Server 8. Network Location Server (NLS IIS site) 9. Configuration Wizard: Infrastructure Servers 10. Configuration Wizard: Application Servers 11. Generate and Activate Policies 12. DirectAccess Connectivity Assistant 13. What won’t work over DirectAccess
Author

Shannon Fritz

Infrastructure Architect & Server Team Lead