Its seems like we’ve run into a little confusion recently regarding how to deploy the UAG DA server in a firewalled environment.

If you look at our documentation for Packet Filtering for the Internet Firewall (http://technet.microsoft.com/en-us/library/ee809062.aspx) you’ll see that we fully support putting a firewall in front of the UAG DA server.

-----------------------------------------------------------------------------------------
Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag
-----------------------------------------------------------------------------------------

To quote Packet Filtering for the Internet Firewall:

“Most organizations use an Internet firewall between the Internet and the computers on their perimeter network. The firewall is typically configured with packet filters that allow specific types of traffic to and from the perimeter network computers. When you add a Forefront UAG DirectAccess server to your perimeter network, you must configure additional packet filters, to allow the traffic to and from the Forefront UAG DirectAccess server for all the traffic that a DirectAccess client uses to obtain IPv6 connectivity to the Forefront UAG DirectAccess server.

The following describes the type of traffic you can configure on your Internet firewall depending on whether the Forefront UAG DirectAccess server is on an IPv4 or IPv6 Internet.

When the Forefront UAG DirectAccess server is on the IPv4 Internet

Configure packet filters on your Internet firewall to allow the following types of IPv4 traffic for the Forefront UAG DirectAccess server:

• Protocol 41 inbound and outbound—For DirectAccess clients that use the 6to4 IPv6 transition technology to encapsulate IPv6 packets with an IPv4 header. In the IPv4 header, the Protocol field is set to 41 to indicate an IPv6 packet payload.
• UDP destination port 3544 inbound and UDP source port 3544 outbound—For DirectAccess clients that use the Teredo IPv6 transition technology to encapsulate IPv6 packets with an IPv4 and UDP header. The Forefront UAG DirectAccess server is listening on UDP port 3544 for traffic from Teredo-based DirectAccess clients.
• TCP destination port 443 inbound and TCP source port 443 outbound—For DirectAccess clients that use IP-HTTPS to encapsulate IPv6 packets within an IPv4-based HTTPS session. The Forefront UAG DirectAccess server is listening on TCP port 443 for traffic from IP-HTTPS-based DirectAccess clients.

When the Forefront UAG DirectAccess server is on the IPv6 Internet

Configure packet filters on your Internet firewall to allow the following types of IPv6 traffic for the Forefront UAG DirectAccess server:

• Protocol 50—Forefront UAG DirectAccess on the IPv6 Internet uses IPsec Encapsulating Security Payload (ESP) to protect the packets to and from the Forefront UAG DirectAccess server without the encapsulation headers required for IPv6 transition technologies. In the IPv6 header, the Protocol field is set to 50 to indicate an ESP-protected payload.
• UDP destination port 500 inbound and UDP source port 500 outbound—Forefront UAG DirectAccess on the IPv6 Internet uses the Internet Key Exchange (IKE) and Authenticated Internet Protocol (AuthIP) protocols to negotiate IPsec security settings. The Forefront UAG DirectAccess server is listening on UDP port 500 for incoming IKE and AuthIP traffic.
• All ICMPv6 traffic inbound and outbound.”

=====================================

However, there has been a cause for confusion in this documentation because some admins confuse firewalling with NAT. While it is true that most firewalls are deployed with NAT enabled, that doesn’t mean you must NAT connections coming through the firewall. In fact, the UAG Infrastructure and Planning Guide (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=110b4c77-b411-4845-9b82-40a733b17003) states:

“Are you deploying Forefront UAG as a DirectAccess server?─A Forefront UAG DirectAccess server can be located behind a firewall or between a frontend and backend firewall, but note that a public IPv4 address is required, and therefore the server should not be located behind a NAT (Network Address Translation) device” [italics mine]

So to answer the question - “can you put the UAG DA server” behind a front-end firewall, the answer is yes. However, that firewall cannot NAT connections between the DirectAccess clients and the UAG DirectAccess Server.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISDiX/SCDiX
UAG Direct Access/Anywhere Access Team
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Forefront UAG supports an enhanced version of DirectAccess that adds several features and capabilities that aren't available with the Windows only version of DirectAccess. After installing UAG on your Windows Server 2008 R2 server, you can then enable DirectAccess using the UAG DirectAccess wizard.

Some administrators have received the message:

"The adapter configured as external-facing is connected to a domain"

after running the DirectAccess wizard. If you receive this message, the DirectAccess wizard will not complete and DirectAccess will not be configured on the UAG DirectAccess server. The reason for this failure is that if the external interface detects that it can reach a domain controller, it will set the Windows Firewall with Advanced Security Profile to "Domain Profile", which will disable the GPO settings required for the DirectAccess server to receive connections from DirectAccess clients (connection security rules, firewall rules, etc).

The cause of this problem isn't well defined right now, but it appears that the problem is related to the UAG DirectAccess activation assuming that the external interface it set for the domain profile in Windows Firewall with Advanced security, although NLA (Network Location Awareness) no longer recognizes that to be true. It could be that the external interface at one time had connectivity to the domain, but later was reconfigured so that subsequently the external interface no longer could access the domain.

If you do run into this issue, you can fix the problem by using the Registry Editor to navigate to the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache\IntranetAuth

Delete all the entries that apply to the external interface - those will be the ones that have the IP addresses assigned to the external interface. From the figure above, those would be:

I’ll continue to follow up on this issue and update the blog with new information as it comes in. But until  then, you have a workaround that will allow you to activate your UAG DirectAccess configuration.

In a recent blog post about an interesting problem we had with understanding Outlook performance issues and the IP-HTTPS adapter, we had the opportunity to review how the various IPv6 transition technology adapters worked in terms of when they were enabled and when they were disabled. If you haven’t seen that post, head on over to The Mystery of the IP-HTTPS Listener, an Outlook Client and an IPv4 Only Network at http://blogs.technet.com/edgeaccessblog/archive/2010/05/09/the-mystery-of-the-ip-https-listener-an-outlook-client-and-an-ipv4-only-network.aspx

One of the things that we got a better understanding of was Teredo adapter behavior. First, Teredo is an IPv6 transition technology that is used by DirectAccess clients when they are located behind a NAT device, and thus are typically assigned a private IP address (RPC 1918). Teredo encapsulates the IPv6 packets in an IPv4 packet with a UDP header. The UAG DirectAccess server listens for connections from Teredo clients on UDP port 3544. Therefore, if the DirectAccess Teredo client has outbound access to the UAG DA server’s UDP port 3544, the Teredo connection can be established.

Teredo Related Group Policy Object Settings

However, before that Teredo connection can be established, the adapter needs to be configured. When you run the UAG DirectAccess Wizard, one of the many things it does it configure a DirectAccess clients Group Policy Object (GPO). The DA Clients GPO (The actual name of the GPO is UAG DirectAccess: Client [GUID]) contains settings for the IPv6 transition technologies used by the UAG DirectAccess clients, and one of these is the Teredo client configuration.

If you go to the following path: Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies you will find Teredo GPO configuration options, as seen in the figure below.

Figure 1

There are two settings that are of the most interest to us. The first one is the Teredo Default Qualified setting, as seen in the figure below. The UAG DirectAccess Wizard leaves this setting at its default. As you can see in the description, “qualified” means that the Teredo interface is ready to communicate. The default setting is Enabled State, which means that the Teredo adapter will go through the process of trying to connect to the UAG DirectAccess server to obtain information required to communicate. Qualification includes determining what type of NAT device the Teredo client is located behind.

Figure 2

The second setting of interest is the Teredo State setting. The UAG DirectAccess wizard leaves the Teredo State at its default setting. The default setting is to set the Teredo state as Client. With this state enabled, the Teredo adapter will come up only if the DirectAccess client is not on a network that has a domain controller on it. If the DirectAccess client detects that it’s on a network with a domain controller, it will disable the Teredo adapter, and the IP-HTTPS adapter will take over, assuming that the IP-HTTPS adapter can establish a connection with the UAG DirectAccess server’s IP-HTTPS listener.

Figure 3

Teredo Clients and Managed Networks

Now the celebrity question is “how does the DirectAccess client determine is there is a domain controller on the network?” That’s a great question, and it’s not easy to find an answer to it. At least it wasn’t easy, until this article was published.

To determine if the DirectAccess client is on a “managed network”, the client performs a DNS query looking for SRV records in the path  _ldap._tcp.dc._msdcs.DnsDomainName, where DnsDomainName is the name of the DNS suffix assigned to the current connection. If SRV records are located, the client assumes it is in a managed network, and Teredo is disabled. If no records are located, the Teredo interface is enabled.

What’s important to know here is that the detected domain can be any domain. It does not need to be the domain that the computer belongs to. Given this to be the case, a DirectAccess client that’s connected to a home network with a domain (a lot of us computer geeks have domains on our home networks) or to a customer’s network that has domain controllers on it, if a DNS query for that SRV record is successful, the Teredo adapter will disable itself when the “Client” state is enabled for the Teredo client. Another important thing to know is that the DA client doesn’t need to connect to the domain controller, it only needs to be able to resolve the name.

Enter the Enterprise Client State (Enterpriseclient)

As you can imagine, this might cause some problems. For example, suppose you connect to your corporate network from your domain-based home network (that’s my situation – I work from home and connect to the Microsoft corpnet over DirectAccess). Because my corporate laptop is connected to a domain-based network, it will detect a domain, and disable the Teredo adapter. In this situation, my Teredo adapter will be disabled and I’ll be forced to use IP-HTTPS, which is a lower performance adapter. Most users would prefer a higher-performance solution (including me), so is there anything we can do about that?

Yes there is – but you’ll need to customize your Group Policy. In Figure 3 , notice that there is another option for setting the Teredo State – that option is Enterprise Client. When you set the Teredo State to Enterprise Client, the Teredo interface will always be present, even if the host is on a network that includes a domain controller. Now, the Teredo adapter will try to activate even when a domain (managed network) is detected.

MSIT decided to do this, as evidence by the figure below. Here you can see the output of the

netsh interface teredo show state

command. Notice that the State is set as qualified – which means that the adapter was able to determine what type of NAT device it was behind, which involves being about to connect to the UAG DirectAccess server. Also, notice the Network setting, which reports as managed. This combination shows that the Teredo adapter was able to connect to the UAG DirectAccess server, it detected a domain network, but remains activated and functional because the Type is set as enterpriseclient (Group Policy).

Figure 4

I need to point out before moving on that if you make these “hand edits” to the UAG DirectAccess Wizard GPO, that they will be overwritten the next time you use the UAG DirectAccess Wizard to update the DirectAccess Client GPO. So you’ll need to create a change control reminder that you need to manually set the Teredo State to Enterprise Client.

What Could Possibly Go Wrong?

Now, while this is a good thing for those of us who want to connect from managed networks (successful domain detection), it does have the potential to cause problems. One example of this is when NLS (Network Location Server)failure takes place, NLA (Network Location Awareness) isn’t able to succeed at domain detection for setting Windows Firewall with Advanced Security (WFAS), with an end result being the WFAS Profile is set to Public or Private (which enables the DirectAccess Connection Security Rules), and the network firewall allows outbound access to UDP port 3544 to the IP address on the external interface of the UAG DirectAccess server. In this scenario (admittedly uncommon) the Teredo adapter will be enabled and intranet communications will take place through the UAG DirectAccess server.

However, given how common domain networks are, and how uncommon the combination of events noted above are, it makes sense to make the default Teredo State Enterprise Client.

For More Information:

Cannot Reach the DirectAccess Server with Teredo

http://technet.microsoft.com/en-us/library/ee844188(WS.10).aspx

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISD iX/SCD iX
UAG Direct Access/Anywhere Access Team
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Jim Harrison recently pointed out to me that there’s a small problem with the UAG DirectAccess Test Lab Guide, which you can find over at http://technet.microsoft.com/en-us/library/ee861167.aspx  If you haven’t seen the Test Lab Guide yet, or if you haven’t had a chance to run it, I highly recommend that you do. We recently updated it with new extensions that enable you to see how UAG specific scenarios such as “manage out”, array deployment, NLB configuration, and access to IPv4 only resources works.

However, back to the “small” problem. Part of the Test Lab Guide walks you through how to install and configure the Microsoft Certificate Server so that Certificate Revocation Checks won’t fail when the DirectAccess client tries to connect to the IP-HTTPS listener on the UAG DirectAccess server.

As I point out in the Test Lab Guide, this isn’t something that you would do in a production environment. If you use a commercial certificate for the IP-HTTPS listener, the certificate provider will make sure the CRL is reachable and highly available. If you create your own certificate for the IP-HTTPS listener, then you’ll have to publish your CRL and make sure it’s highly available – a lot of work for some people, not so much for others. The point is, you can do it either way.

If you go to http://technet.microsoft.com/en-us/library/ee861152.aspx#BKMK_O you’ll find that you’re in Section O – Remove CRL Distribution Settings on the Certificate Authority on DC1. In step 3, you’ll read the following:

“3. Click the Extensions tab. In Specify locations for which users can obtain a certificate revocation list, check all locations of the CRL Distribution Point (CDP) Authority Information Access (AIA), and verify that Publish CRLs to this location or Publish Delta CRLs to this location is not selected.”

The problem with these instructions is that they are incomplete and won’t prevent CRL check failure when the DirectAccess client is later configured to connect to the UAG DirectAccess server using its IP-HTTPS adapter. You’ll know that you’re running into this problem when you run the command

netsh interface httpstunnel show interface

you’ll see a Last Error Code of 0x80092013. You might also see an error code of 0x274c on the way to the the interface finally failing. The 0x80092013 code indicates that the CRL check failed.

In the figure below you can see the Properties dialog box for the Certificate Authority we use in the Test Lab Guide. The problem you’re encounter with the Test Lab Guide is related to the ldap:// URI. When you select that option from the Specify location from which users can obtain a certificate revocation list (CRL), you have to make sure that you deselect (uncheck) the option Include in the CDP extension of issued certificates. That step is not called out in the Test Lab Guide. I will add that as soon as I can, but until then, make sure you uncheck that option.

What if you already configured the Test Lab and everything worked except for the IP-HTTPS connection? What you can do is request a new certificate for the IP-HTTPS listener and run the UAG DirectAccess Wizard again so that the new certificate is bound to the IP-HTTPS listener. Here are the general steps

1. First, configure the Certificate Authority so that the ldap:// URI has the Include in the CDP extension of issued certificates option unchecked, as seen in the figure above. You will be asked to restart the CA in the process.
2. Disable the DirectAccess configuration at the UAG server. You can do that in the UAG management console. Click the Disable button and it will disable the UAG DirectAccess configuration while you’re making your updates. 
   
3. After you disable the UAG DirectAccess configuration, the next step is to configure the TMG firewall located on the UAG server to allow you to request certificates from the Certificate Authority on the internal network. For instructions on how to do that, see Ben Bernstein’s post on the UAG Team Blog at http://blogs.technet.com/edgeaccessblog/archive/2010/04/22/deep-dive-into-uag-directaccess-certificate-enrollment.aspx
4. Open the Certificates MMC on the UAG server. Delete the previous IP-HTTPS certificate, which will show Issued To as uag1.contoso.com as seen in the figure below. 
   
5. After configuring the TMG firewall to allow you to use the Certificate Request Wizard in the Certificates MMC and deleting the old IP-HTTPS certificate, request a new web site certificate for the IP-HTTPS listener. The common and DNS names should be the same as the previous certificate, uag1.contoso.com. You will use the same certificate template you used earlier in the lab, which was the Web Server 2003 template.
6. After the new certificate is installed, right click on the new certificate and click Properties. In the Friendly name text box, give it a new name so that you can find it easily in the UAG DirectAccess wizard. In this example, added the friendly name IP-HTTPS2 Cert. 
   
7. Run the UAG DirectAccess Wizard again. When you get to the Authentication Options page of the UAG DirectAccess Server Configuration sub-wizard, click the Browse button in the Select the certificate that authenticates the UAG DirectAccess server to a client connecting using IP-HTTPS. You will see the new IP-HTTPS in the list – select that one. 
     
    
8. Complete the UAG DirectAccess Wizard and deploy the new GPOs. Then click the Activate button to activate the UAG DirectAccess server configuration.
9. Restart the CLIENT1 virtual machine. When the virtual machine comes up, it will be able to connect using IP-HTTPS. If the Teredo client is still set to enterpriseclient, then run the command netsh interface teredo set state diable and wait for the OK response. At that point the IP-HTTPS connection will establish and you’ll see it when you run ipconfig /all

When you see it work, your output will look something like the figure below

 

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISD iX/SCD iX
UAG Direct Access/Anywhere Access Team
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder