UAG DirectAccess and the Windows Firewall with Advanced Security – Things You Should Know

Both the Windows DirectAccess and the UAG DirectAccess solutions are heavily dependent on the Windows Firewall with Advanced Security. DirectAccess clients take advantage of both firewall rules and Connection Security Rules. Connection Security Rules are IPsec rules that control the IPsec tunnel mode connections between the DirectAccess clients and the DirectAccess server. In addition to the IPsec tunnel mode connections, Connection Security Rules are used to enable IPsec transport mode connections for servers for which you want the DirectAccess clients to connect using end-to-end security.

In order to get the most out of DirectAccess and how DirectAccess works, it helps to have a better understanding of the different components of the Windows Firewall with Advanced Security and how some of the important settings work and how they interact with DirectAccess

Windows Firewall Profiles – Public Profile, Private Profile and Domain Profile

Windows Firewall offers three firewall profiles: domain, private and public. The domain profile applies to networks where the host system can authenticate to a domain controller. The private profile is a user-assigned profile and is used to designate private or home networks. Lastly, the default profile is the public profile, which is used to designate public networks such as Wi-Fi hotspots at coffee shops, airports, and other locations.

Different firewall and connection security rules can be configured for each profile. There are default settings that are applied to each profile, but the administrator can customize their default settings.

What Does This Have to Do with DirectAccess?

The different profiles are important because a computer only works as a DirectAccess client when it is not on the corporate network. In order words, if the DirectAccess client detects that it can connect to its domain controller and is on the corporate network, it will use the domain profile. The DirectAccess client will only act as a DirectAccess client when the Private or Public Profiles are enabled. The reason for this is that the Connection Security Rules that enable the IPsec tunnel mode connections to the DirectAccess server are included only in the Public or Private Profiles. There are no Connection Security Rules that enable IPsec tunnel mode connections to the DirectAccess server in the Domain Profile.

The UAG DirectAccess server (as well as the Windows DirectAccess server) will create the Connection Security Rules that allow for the creation of the DirectAccess IPsec tunnels (and the end-to-end IPsec transport mode connections for servers configured for end-to-end security). However, the UAG DirectAccess wizard does not import any firewall rules that you might have configured to work on the corporate network. Those rules that you created for the intranet hosts were created for the Domain Profile. If you want your Domain Profile firewall rules to apply to DirectAccess clients, you will need to enable those rules on the Public Profile and Private Profile too.

How Do I Create Firewall Rules for DirectAccess Clients?

In order for intranet computers to connect to DirectAccess clients, there need to be firewall rules in place on the DirectAccess clients that allow the incoming connections from the intranet servers. In addition, if you are blocking outbound connections, you may need to create rules that enable required protocols outbound. There are several things you need to know about these firewall rules:

• Teredo clients need to have the Edge Traversal setting enabled on inbound firewall rules that allow the intranet clients to connect to DirectAccess clients that are using Teredo to connect to the DirectAccess server (https://technet.microsoft.com/en-us/library/ee809076.aspx)
• Teredo clients must have also have rules that allow them ICMPv6 access to intranet clients, such as ICMPv6 neighbor discovery. This rule is enabled by default and you should not delete it. In addition, Teredo clients require ICMPv6 Echo Request access to your intranet if you are using ISATAP or native IPv6 on the intranet. If you are using NAT64/DNS64, then you need to enable ICMPv4 Echo Requests to your intranet (https://technet.microsoft.com/en-us/library/ee649189(WS.10).aspx).
• With reference to the second bullet point, you should be aware of a scenario where domain policy doesn’t allow firewall rules to merge with local policy. While the required rule is enabled by default in local policy, if your organization disables merging local with domain policy, then only rules created for domain policy will be applied to the DirectAccess client, which will cause this rule to be disabled. If this is the case, you should manually create all of the required infrastructure rules, such as those required for IP-HTTPS, Teredo, 6to4, ESP, IKE and ICMPv6.
• DirectAccess clients using 6to4 and IP-HTTPS to connect to the UAG DirectAccess server don’t require the Edge Traversal setting to allow for remote management. However, since you can’t predict which IPv6 transition protocol will be used by the DirectAccess client, you should always enable Edge Traversal on the firewall rules.
• The firewall rules that enable intranet hosts to connect to the DirectAccess clients should be applied to the Public and Private profiles. You can apply them to the domain profile if you like, but in order for the computer that is acting as a DirectAccess client to apply these rules, they must be enabled on the Public and Private Profiles.
• When creating these firewall rules, make sure that one of the endpoints (can be the remote endpoint, it doesn’t matter) includes the IPv6 prefix of the intranet. Failing to configure this type of access control in the rule may create a security issue that allows anyone on the Internet to connect to the DirectAccess client using these protocols. You can find the ISATAP IPv6 prefix in the details of the intranet tunnel rule as Endpoint 2.
• If you have firewall rules that you enable for intranet clients using the Domain profile, be aware that these are not automatically applied to the DirectAccess clients, since they will be using either the Public or Private profile. Therefore, if you want your domain firewall rules applied to DirectAccess clients, make sure to replicate them for your DirectAccess clients’ Public and Private profiles.

While it’s possible for you to create your firewall rules in the DirectAccess Clients GPO, that’s not a good idea because your rules will be overwritten the next time you use the UAG DirectAccess wizard and deploy updated GPO settings. Instead, create a new GPO with the firewall settings and apply it to your DirectAccess clients security group or OU.

For a very good tutorial on configuring firewall rules for DirectAccess client, check out How to enable Remote Desktop Sharing (RDS/RDP) from corporate machines to DirectAccess connected machine at https://blogs.technet.com/b/edgeaccessblog/archive/2010/09/14/how-to-enable-remote-desktop-sharing-rds-rdp-from-corporate-machines-to-directaccess-connected-machines.aspx

And if you want to try it out for yourself in your UAG DirectAccess Test Lab, check out Test Lab Guide: Demonstrate UAG DirectAccess Remote Management over at https://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=385a3144-8e84-4335-896b-a2927e4d46cd

Anything Else I Need to Know About DirectAccess Client Firewall Rules?

I’m glad you asked! Yes, there are a few more things you should think about when configuring firewall rules for DirectAccess clients. These are:

• Don’t turn off the Windows Firewall on either the DirectAccess client or DirectAccess server. This will disable IPsec and Edge Traversal – so it essentially breaks all DirectAccess connectivity
• Avoid allowing all inbound connections to the DirectAccess clients. Doing so will disable Edge Traversal. This breaks Teredo and manage-out.
• Avoid blocking all outbound connections as well. If you block all outbound traffic, you will not only need to enable the infrastructure protocols, you will also need to allow any other protocol required by the DirectAccess client, such as HTTP, SMT, RDP, etc) on the Public and Private Profiles.
• If your organization manages all of your firewall rules through a central GPO, you need to make sure that you enable the rules that are required for DirectAccess to work. These include rules to support IPv6 Transition Technologies, ICMPv6 (as mentioned previously)and ESP and AuthIP. However, you do not need to any rule to the UAG server, as the Firewall capability is disabled on the UAG and the TMG server is in control.

Authors:

Yaniv Naor, SDE
Tom Shinder, Knowledge Engineer/Principal Technical Writer, Anywhere Access Group (AAG)

Comments

• Anonymous
  December 01, 2010
  The comment has been removed

• Anonymous
  December 01, 2010
  The comment has been removed

• Anonymous
  December 03, 2010
  OK guys - very funny! I'm fixing it now :) Thanks! Tom

• Anonymous
  August 08, 2014
  Please Note: The approach provided within this blog post is not suitable when using an External Load