Archive
Forefront TMG 2010 Protocols and Ports Reference
When deploying Forefront TMG 2010 as a forward or reverse proxy, many organizations will place their TMG firewalls in a perimeter or DMZ network to provide an additional layer of protection for their proxies. When deployed in this manner, configuring perimeter firewalls to allow proper communication to and from the Forefront TMG firewall can be challenging. Although the Service Overview and Network Port Requirements for Windows document on TechNet includes information about ISA server (which also applies to TMG) it includes all protocols and ports used by TMG in all deployment scenarios. This can be confusing when you simply want to allow TMG firewalls in a perimeter network to communicate with an Enterprise Management Server (EMS) on the internal network, or simply manage a TMG firewall in a perimeter network from a management workstation on the internal network. Opening all of the ports listed in the Microsoft KB article mentioned above would be unnecessary and would violate the principle of least privilege, which dictates that only the specific ports required for communication should be opened.
Note: This reference covers typical TMG configurations and may not include all protocols and ports required for every deployment scenario. For example, if you are using RADIUS or RSA for authentication, have configured connectivity verifiers or a remote SQL server, or have deployed Forefront TMG 2010 for Exchange integration, each of these configurations will require additional perimeter firewall access. Also, don’t forget that your perimeter firewalls will need to allow access to the protocols and ports required for the services you are accessing/publishing through Forefront TMG 2010.
For reference, here are the protocols and ports required for specific, common Forefront TMG 2010 deployment scenarios:
EMS to TMG
TCP 135, 10000-65535* – RPC
TCP 3847 – MS Firewall Control
TMG to EMS
TCP 445 – CIFS
UDP 445 – CIFS
TCP 2171 – MS Firewall Storage (domain-joined only)
TCP 2172 – MS Firewall Storage Secure (workgroup mode only)
TCP 3847 – MS Firewall Control
TMG to DCs
Domain joined…
TCP 88 – Kerberos
UDP 88 – Kerberos (send receive)
UDP 123 – NTP
TCP 135, 49152-65535* – RPC
TCP 389 – LDAP
UDP 389 – LDAP
TCP 445 – CIFS
UDP 445 – CIFS
TCP 3268 – LDAP Global Catalog
Non domain-joined…
TCP 389 – LDAP (required only for pre-authentication in reverse proxy scenarios)
TCP 636 – LDAPS (required only for pre-authentication in reverse proxy scenarios)
TMG to DNS
TCP 53 – DNS (send receive)
UDP 53 – DNS
Primary EMS to Replica EMS
TCP 135, 49152-65535* – RPC
TCP 2173 – MS Firewall Storage Replication
Replica EMS to Primary EMS
TCP 135, 49152-65535* – RPC
TCP 445 – CIFS
UDP 445 – CIFS
TCP 2171 – MS Firewall Storage – domain-joined only
TCP 2172 – MS Firewall Storage (Secure) – workgroup mode only
TCP 3847 – MS Firewall Control
Web Proxy Client to TMG
TCP 80 – HTTP (WPAD only)
TCP 8080 – HTTP Proxy
Firewall Client to TMG
TCP 80 – HTTP (WPAD only)
TCP 1745 – Firewall Client Control Channel
UDP 1745 – Firewall Client Control Channel
TCP 1024-65535 – All high ports**
UDP 1024-65535 – All high ports**
Management Workstation to TMG
TCP 135, 10000-65535* – RPC
TCP 2171 – MS Firewall Storage – Domain mode only
TCP 2172 – MS Firewall Storage (Secure) – Workgroup mode only
TCP 3847 – MS Firewall Control
*The default dynamic port range for Windows Server 2008 R2 is 49152-65535. When TMG is installed this setting is changed to 10000-65535. This does not apply to TMG EMS, however. RPC can be configured to use a smaller range of dynamic ports, if necessary. For more information, please see Microsoft KB 154956.
**The Forefront TMG 2010 Firewall Client is designed to operate without a firewall between itself and the TMG firewall. It is highly recommended that you avoid this design whenever possible. If this is unavoidable, all TCP and UDP high ports will have to be opened, as the TMG Firewall Client control channel utilizes random high ports and cannot be restricted as RPC can.
Forefront TMG 2010 Protocol Direction Explained
When reviewing the configuration of a pre-defined protocol or creating a custom protocol on the Forefront TMG 2010 firewall, many new (and sometimes even veteran) firewall administrators can be confused by the protocol direction. The correct configuration of the protocol direction is essential for proper firewall operation, but there are times when it can be somewhat unintuitive. In this post I’ll provide some clarification.
TCP
For TCP protocols the direction can be specified as either inbound or outbound.
For access rules, protocol direction is configured as outbound. Traffic flows outbound from the source to the destination. This is true even when creating an access rule to allow traffic inbound to the Forefront TMG 2010 firewall itself. It sounds counterintuitive, but the TCP protocol direction for access rules allowing access to the Local Host network should still be outbound. Why? Again, because traffic flows outbound form the source to the destination, in this case the TMG firewall’s Local Host network. If, in this case, you were to configure the protocol direction as Inbound (intuitively, inbound to the TMG firewall) it will not work.
For publishing rules, protocol direction is configured as inbound. Traffic flows inbound from the source to the published service on the Forefront TMG 2010 firewall. Pre-defined server publishing protocols include the “server” suffix, as shown here:
UDP
For UDP protocols the direction can be specified as either Receive, Receive Send, Send, or Send Receive.
For access rules, protocol direction is configured as Send. Traffic is sent from the source to the destination. If a response is expected then the protocol direction is configured as Send Receive. This is required because UDP is connectionless and the return traffic would otherwise be denied by the TMG firewall.
For publishing rules, protocol direction is configured as Receive. Traffic is received by the TMG firewall from the source to the published service on the Forefront TMG 2010 firewall. If a response is expected then the protocol direction would be configured as Receive Send.
IP and ICMP
For IP and ICMP protocols the direction can be specified as either Send or Send Receive.
IP and ICMP protocol definitions are only supported for access rules, so protocol direction is configured as Send. As with UDP, IP and ICMP are connectionless and if a response is expected then the protocol direction is configured as Send Receive.
Connect
Richard Hicks' Forefront TMG Blog 