UAG SP1 DirectAccess: Firewalls and TMG Settings

Author by Shannon Fritz

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

If you use another firewall on either side of the UAG server, the following rules need to be configured on that firewall to allow inbound traffic for both of the External IP's on your UAG server:
  • 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) [optional].
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. NOTE: The firewalls that your DirectAccess clients use do not need to be changed in order for DirectAccess to work as they will use whatever ports are available. These changes are only required on your corporate firewall so the UAG server can support all three connection types for your clients.

UAG/TMG Firewall

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.  In my previous guide I showed how to modify the rule to allow these things but Jason Jones pointed out that there is a much easier (and supported!) way of doing this. You just add your computer or a subnet to the Remote Management Computers list in TMG.

Remote Management

On the UAG server open the Forefront TMG console and select the Firewall Policy on the left. On the right, scroll down and click "Edit System Policy. Now select Microsoft Management and make sure "Enable this configuration group" is checked on the general tab and then select the From tab. Click the Remote Management Computers source and click Edit. Here you can add a specific computer (like your workstation) or a complete subnet (maybe you have a server VLAN) that you want to grant the ability to remote desktop into the UAG server. While you're in there you should also remove the requirement for "strict RPC compliance". Requesting a certificate from your PKI will not work if this is enforced which will break auto-enrollment renewals and requests for other certificates (like the IP-HTTPS certificate if you haven't generated that already). Edit the system policy like you did above but this time select Active Directory. Now clear the checkbox for "Enforce strict RPC compliance." And now you should be able to remotely manage your UAG server and connect with Remote Desktop.

Add Firewall Exceptions

Before making changes to the Firewall rules in TMG I should point out that Microsoft support advises against doing it at all. It is supported, but it falls into a kind of grey area because UAG puppeteers the creation of and changes to many TMG rules. So there is potential that a rule you make could cause problems or pose a security risk. For that reason, I would especially not make any changes that affect the External interface.

That being said, there are two exceptions that I generally find useful: Allowing all traffic from the UAG server to your Certificate Server and allowing the UAG server to respond to a PING requests. You do not need to create these rules so you can skip them if you'd rather not mess with TMG anymore. 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 place your rule at the very bottom, just before the "Deny All" rule. You could also place the rule all the way at the top but do not place it someplace in the middle as this is where UAG's rules go and you don't want to monkey around with that.

Allow all traffic to your CA

Without this firewall exception, certificate renewals will fail with an error stating that "The RPC Server is unavailable" as described here. Start the Add Rule wizard and call it something like "CA Connectivity", click next and set the action to "Allow".  For "Selected Protocols" click select "All outbound traffic" and then click Next.  For the Sources click Add, expand Networks and add Local Host.  Click Close, then Next.  For Destination click Add and select your Certificate Server. You may need to click the New menu and add a new Computer to the list. When you're done click Close and then Next.  Leave the default "All Users" in for User Sets and click Next.  Review the summary and click Finish.

Allow PING

There are two reasons to allow PING on your UAG server. One is because you like to ping your servers (common) and the other is because it is needed to support Teredo and NAT64/DNS64 (more significant). NOTE: This goes against the advice to not make a rule that affects the external interface, but unless you are using force tunneling (which requires IP-HTTPS), I would make this exception. Here's a forum thread on the topic. Make a rule named "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. 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 this particular rule, if the UAG server is behind another firewall then you will need allow ping through there firewall as well.

Apply Changes

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.

Windows Firewall Rules in your Domain

Many places use Group Policy to mange the client firewall of their workstations, which is great, but make sure that the Public Profile of the firewall is enabled. If this profile is off (or worse, if the firewall service is disabled) then DirectAccess will not work. This also means that if you have applications that initiate connections to your clients, then you will need to make firewall exceptions to allow those incoming ports or the connection can fail. For an example, here's a thread about using the SCCM Remote Tools to connect to a DirectAccess client. Also, to better support Teredo connections, as well as aid in troubleshooting, you should create a Firewall exception that allows your domain computers to reply to PING requests (ICMP Echo) over both IPv4 and IPv6. The easiest way to do this is by creating a Group Policy that makes these exceptions for you throughout your domain. Check out Tom's test Lab Guide step 2G for the steps on how to do that.
Author

Shannon Fritz

Infrastructure Architect & Server Team Lead