Swedish Windows Security User Group

As discussed in the following blog, the Forefront Threat Management Gateway (TMG) Web Protection Services will be discontinued on December 31st, 2015:-

http://blogs.technet.com/b/applicationproxyblog/archive/2015/11/02/important-reminder-for-forefront-threat-management-gateway-tmg-web-protection-services-customers.aspx

We wanted to provide some additional details on what this will affect and recommendations on actions you should be taking.

The services that will be affected by this are:-

– URL Categorization
– Malware Inspection

Importantly, the Microsoft Reputation Services that supports URL Filtering will be turned off on or shortly after the 31^st December 2015.

To avoid service impacting issues due to these services no longer being available, or incorrect rule processing where rules rely on URL Categorization categories, we would strongly advise customers review and amend their TMG configurations as follows:-

– Review and amend any rules based on URL Categorization categories in your TMG policy

Any Allow and Deny rules that currently use URL Categories or URL Category Sets must be changed to remove the usage of URL filtering categories.

Using URL Sets or Domain Name Sets may provide limited replacement functionality or you may also want to consider a 3^rd party URL filtering plug-in or upstream proxy service to provide replacement URL filtering functionality.

Note – If you have rules that are using URL filtering to allow traffic – HTTP traffic can be totally blocked after the service shutdown. Equally, if you use URL Filtering to block access to certain categories then these may be allowed after the change. There is also a possibility that performance issues will be seen if URL Filtering is left enabled after the MRS service is taken offline.

– Disable URL Filtering

After amending your TMG policy ensure you then disable URL Filtering. This can be done in the TMG Management Console in the Web Access Policy node by selecting URL Filtering and unchecking the “Enable URL Filtering” check-box. This is essential to avoid TMG trying to contact the MRS services after they go offline.

– Malware Inspection may continue to work but would not receive updated signatures

We would recommend implementing an alternative Anti-Virus solution and to disable Malware Inspection once this is in place.

As noted in the previous blog, Forefront Threat Management Gateway 2010, remains under extended support until April 14, 2020.

For details on moving from TMG to our new web publishing solutions please visit this URL:

http://blogs.technet.com/b/applicationproxyblog/archive/2015/07/02/transitioning-to-application-proxy-from-uag-and-tmg.aspx

Some Frequently Asked Questions we’ve had regarding the change are:-

Q1. Is it possible to use the MRS Cache to continue to benefit from URL Filtering after 31^st December 2015?

A1. No, the MRS cache is a temporary in-memory cache of the latest lookups intended to provide internal efficiency optimizations. It does not provide a full offline cache and cannot be used for this purpose. There is no mechanism to have an offline database.

Q2. Is it possible to extend our usage of Forefront Threat Management Gateway (TMG) Web Protection Services past 31^st December 2015?

A2. No, this is not possible. These dates were announced in September 2012 in order to provide sufficient time for alternative solutions to be deployed.

For the original announcement of the Forefront product roadmap changes please refer to the following URL:

http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx

As discussed in the following blog, the Forefront Threat Management Gateway (TMG) Web Protection Services will be discontinued on December 31st, 2015:-

http://blogs.technet.com/b/applicationproxyblog/archive/2015/11/02/important-reminder-for-forefront-threat-management-gateway-tmg-web-protection-services-customers.aspx

We wanted to provide some additional details on what this will affect and recommendations on actions you should be taking.

The services that will be affected by this are:-

– URL Categorization
– Malware Inspection

Importantly, the Microsoft Reputation Services that supports URL Filtering will be turned off on or shortly after the 31^st December 2015.

To avoid service impacting issues due to these services no longer being available, or incorrect rule processing where rules rely on URL Categorization categories, we would strongly advise customers review and amend their TMG configurations as follows:-

– Review and amend any rules based on URL Categorization categories in your TMG policy

Any Allow and Deny rules that currently use URL Categories or URL Category Sets must be changed to remove the usage of URL filtering categories.

Using URL Sets or Domain Name Sets may provide limited replacement functionality or you may also want to consider a 3^rd party URL filtering plug-in or upstream proxy service to provide replacement URL filtering functionality.

Note – If you have rules that are using URL filtering to allow traffic – HTTP traffic can be totally blocked after the service shutdown. Equally, if you use URL Filtering to block access to certain categories then these may be allowed after the change. There is also a possibility that performance issues will be seen if URL Filtering is left enabled after the MRS service is taken offline.

– Disable URL Filtering

After amending your TMG policy ensure you then disable URL Filtering. This can be done in the TMG Management Console in the Web Access Policy node by selecting URL Filtering and unchecking the “Enable URL Filtering” check-box. This is essential to avoid TMG trying to contact the MRS services after they go offline.

– Malware Inspection may continue to work but would not receive updated signatures

We would recommend implementing an alternative Anti-Virus solution and to disable Malware Inspection once this is in place.

As noted in the previous blog, Forefront Threat Management Gateway 2010, remains under extended support until April 14, 2020.

For details on moving from TMG to our new web publishing solutions please visit this URL:

http://blogs.technet.com/b/applicationproxyblog/archive/2015/07/02/transitioning-to-application-proxy-from-uag-and-tmg.aspx

Some Frequently Asked Questions we’ve had regarding the change are:-

Q1. Is it possible to use the MRS Cache to continue to benefit from URL Filtering after 31^st December 2015?

A1. No, the MRS cache is a temporary in-memory cache of the latest lookups intended to provide internal efficiency optimizations. It does not provide a full offline cache and cannot be used for this purpose. There is no mechanism to have an offline database.

Q2. Is it possible to extend our usage of Forefront Threat Management Gateway (TMG) Web Protection Services past 31^st December 2015?

A2. No, this is not possible. These dates were announced in September 2012 in order to provide sufficient time for alternative solutions to be deployed.

For the original announcement of the Forefront product roadmap changes please refer to the following URL:

http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx

As discussed in the following blog, the Forefront Threat Management Gateway (TMG) Web Protection Services will be discontinued on December 31st, 2015:-

http://blogs.technet.com/b/applicationproxyblog/archive/2015/11/02/important-reminder-for-forefront-threat-management-gateway-tmg-web-protection-services-customers.aspx

We wanted to provide some additional details on what this will affect and recommendations on actions you should be taking.

The services that will be affected by this are:-

– URL Categorization
– Malware Inspection

Importantly, the Microsoft Reputation Services that supports URL Filtering will be turned off on or shortly after the 31^st December 2015.

To avoid service impacting issues due to these services no longer being available, or incorrect rule processing where rules rely on URL Categorization categories, we would strongly advise customers review and amend their TMG configurations as follows:-

– Review and amend any rules based on URL Categorization categories in your TMG policy

Any Allow and Deny rules that currently use URL Categories or URL Category Sets must be changed to remove the usage of URL filtering categories.

Using URL Sets or Domain Name Sets may provide limited replacement functionality or you may also want to consider a 3^rd party URL filtering plug-in or upstream proxy service to provide replacement URL filtering functionality.

Note – If you have rules that are using URL filtering to allow traffic – HTTP traffic can be totally blocked after the service shutdown. Equally, if you use URL Filtering to block access to certain categories then these may be allowed after the change. There is also a possibility that performance issues will be seen if URL Filtering is left enabled after the MRS service is taken offline.

– Disable URL Filtering

After amending your TMG policy ensure you then disable URL Filtering. This can be done in the TMG Management Console in the Web Access Policy node by selecting URL Filtering and unchecking the “Enable URL Filtering” check-box. This is essential to avoid TMG trying to contact the MRS services after they go offline.

– Malware Inspection may continue to work but would not receive updated signatures

We would recommend implementing an alternative Anti-Virus solution and to disable Malware Inspection once this is in place.

As noted in the previous blog, Forefront Threat Management Gateway 2010, remains under extended support until April 14, 2020.

For details on moving from TMG to our new web publishing solutions please visit this URL:

http://blogs.technet.com/b/applicationproxyblog/archive/2015/07/02/transitioning-to-application-proxy-from-uag-and-tmg.aspx

Some Frequently Asked Questions we’ve had regarding the change are:-

Q1. Is it possible to use the MRS Cache to continue to benefit from URL Filtering after 31^st December 2015?

A1. No, the MRS cache is a temporary in-memory cache of the latest lookups intended to provide internal efficiency optimizations. It does not provide a full offline cache and cannot be used for this purpose. There is no mechanism to have an offline database.

Q2. Is it possible to extend our usage of Forefront Threat Management Gateway (TMG) Web Protection Services past 31^st December 2015?

A2. No, this is not possible. These dates were announced in September 2012 in order to provide sufficient time for alternative solutions to be deployed.

For the original announcement of the Forefront product roadmap changes please refer to the following URL:

http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx

Some of you may have already heard and know what NLB is and how it works as described in the general Network Load Balancing Overview [http://technet.microsoft.com/en-us/library/cc725946.aspx].

An integral part of a TMG NLB solution is Bi-direction affinity, which is well described at the following link:

Bi-Directional Affinity in ISA Server [http://blogs.technet.com/b/isablog/archive/2008/03/12/bi-directional-affinity-in-isa-server.aspx].

Bi-directional affinity creates multiple instances of Network Load Balancing (NLB) on the same host, which work in tandem to ensure that responses from published servers are routed through the appropriate ISA servers in a cluster. Bi-directional affinity is commonly used when NLB is configured with Internet Security and Acceleration (ISA) servers. If bi-directional affinity is not consistent across all NLB hosts or if NLB fails to initialize bi-directional affinity, the NLB cluster will remain in the converging state until a consistent teaming configuration is detected.

Bi-directional affinity is a crucial thing if you enable NLB on multiple interfaces, as it ensures a single client to work through the same node and have consistent data flow.

By default when a client connects to an NLB interface a hash algorithm based on the packet source IP (client) is computed in the NLB driver to decide which NLB node should handle this request. On the way back (the server responses to the client) the source IP is the server IP (not the client IP) and without BDA it may be handled by another TMG NLB node – which would discard the server response, not having seen the client request. Hence, a mechanism is needed to guarantee that client/server packets are handled by the same host in the array.

Bidirectional affinity ensures the server responses are handled by the same TMG NLB node as the original client request. The mechanism ensuring this functionality is implemented as  so-called hook rules:

http://technet.microsoft.com/en-us/library/dd348817(v=ws.10).aspx

Filter hooks help to direct traffic in a Network Load Balancing (NLB) cluster by filtering network packets. If the filter hooks are not properly configured, the NLB cluster will continue to converge and operate normally, however, the server application that is running with NLB will not be able to properly register the hooks.

The essential logic of the hook rules is the following:

At each packet, NLB calls out to the registered drivers (in this case fweng) whether they want to modify how the hash is created.

For example, when a client sends a SYN packet, NLB “asks” TMG’s fweng driver how it should calculate the hash. TMG will tell (depending on its hook rules) to use for example the client source IP for hashing (which is the default behavior). The calculated hash instructs NLB for example that the first node should handle the traffic and pass the SYN to the backend server.

When the server responds to the internal NLB of the TMG array, NLB calls out again to ask TMG how the hash is supposed to be calculated.

Based on the same hook rule set and seeing the packet direction, TMG  tells NLB to hash based on the destination IP, which is again the client IP, so the packet will be handled by the same node as the original packet.

If the hook rule was not present , TMG would tell to use the default behavior (use the source IP), which would result in  calculating the hash based on the  source (server) IP, possibly yielding that a different node is supposed to handle the traffic, which is not what we want.

If  you have a TMG array with several nodes and NLB is enabled, then TMG service creates hook rules at start.

These rules can be checked by executing netsh tmg show nlb from an elevated command prompt, which yields similar output as can be seen below.

Notice the rules have a source and destination range, and a direction based on which TMG can decide what to tell NLB when its called: whether to hash on source (forward) or destination IP (reverse).

A potential problem occurs if hook rules are missing. In this post, we are going to explore a potential cause for missing hook rules.

The below is from a sample test lab which we built based on a particular issue we got reported by a customer:

In  the example above we can see only rules which were created and hash based on source (forward direction) for outgoing scenario. 

You however do not see any reverse rules, indicating that some rules may be missing .

I took those rules from my TMG Array with Internal 10.0.0.0/24, DMZ 192.168.0.0/24 and External 172.20.1.0/24 networks.

Let's imagine a scenario where we have created a publishing rule for a server from DMZ with a listener on External network and you have configured the rule to be half NAT (request appears from client).

Because there is no specific rule for the range external network -> DMZ, DMZ -> external, in both directions we use the default behavior to hash based on the source IP.

As described above, because the hook rule is missing, this may or may not work depending on client IP/published server twin. If the NLB hash algorithm gives the same NLB node ID for both the client and the server IP , it will work. Otherwise, client and server packets will be serviced by different hosts, and the published server responses will be dropped with   the  error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED.

The reason of the issue is lack of some NLB hook rules.

These rules are created at the startup based on network rules. In a real world scenario, when we may have a lot of subnets, it's quite easy to miss a network rule between two networks.

In this case, this is exactly what happened –  there was no network relationship defined between External and DMZ, hence the appropriate rule was never created

Once we add the network rule, the hook rules will be created. I created the rule from External to DMZ network with Route relationship. In the output below you can see how hook rules changed.

Now we have appropriate rules for processing requests from External to DMZ network back and forth, ensuring that we hash using the same IP in both directions. Hence, we should not get error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED any more.

If you see the above error, make sure to check whether the appropriate hook rules are present – one of the root causes for missing hook rules can be the missing network relationship definition.

Author:

Vasily Kobylin, Senior Support Engineer, Microsoft EMEA Forefront Edge

Reviewer:

Balint Toth, Senior Support Escalation Engineer, Microsoft EMEA Forefront Edge

Franck Heilmann, Senior Escalation Engineer, Microsoft EMEA Forefront Edge

Some of you may have already heard and know what NLB is and how it works as described in the general Network Load Balancing Overview [http://technet.microsoft.com/en-us/library/cc725946.aspx].

An integral part of a TMG NLB solution is Bi-direction affinity, which is well described at the following link:

Bi-Directional Affinity in ISA Server [http://blogs.technet.com/b/isablog/archive/2008/03/12/bi-directional-affinity-in-isa-server.aspx].

Bi-directional affinity creates multiple instances of Network Load Balancing (NLB) on the same host, which work in tandem to ensure that responses from published servers are routed through the appropriate ISA servers in a cluster. Bi-directional affinity is commonly used when NLB is configured with Internet Security and Acceleration (ISA) servers. If bi-directional affinity is not consistent across all NLB hosts or if NLB fails to initialize bi-directional affinity, the NLB cluster will remain in the converging state until a consistent teaming configuration is detected.

Bi-directional affinity is a crucial thing if you enable NLB on multiple interfaces, as it ensures a single client to work through the same node and have consistent data flow.

By default when a client connects to an NLB interface a hash algorithm based on the packet source IP (client) is computed in the NLB driver to decide which NLB node should handle this request. On the way back (the server responses to the client) the source IP is the server IP (not the client IP) and without BDA it may be handled by another TMG NLB node – which would discard the server response, not having seen the client request. Hence, a mechanism is needed to guarantee that client/server packets are handled by the same host in the array.

Bidirectional affinity ensures the server responses are handled by the same TMG NLB node as the original client request. The mechanism ensuring this functionality is implemented as  so-called hook rules:

http://technet.microsoft.com/en-us/library/dd348817(v=ws.10).aspx

Filter hooks help to direct traffic in a Network Load Balancing (NLB) cluster by filtering network packets. If the filter hooks are not properly configured, the NLB cluster will continue to converge and operate normally, however, the server application that is running with NLB will not be able to properly register the hooks.

The essential logic of the hook rules is the following:

At each packet, NLB calls out to the registered drivers (in this case fweng) whether they want to modify how the hash is created.

For example, when a client sends a SYN packet, NLB “asks” TMG’s fweng driver how it should calculate the hash. TMG will tell (depending on its hook rules) to use for example the client source IP for hashing (which is the default behavior). The calculated hash instructs NLB for example that the first node should handle the traffic and pass the SYN to the backend server.

When the server responds to the internal NLB of the TMG array, NLB calls out again to ask TMG how the hash is supposed to be calculated.

Based on the same hook rule set and seeing the packet direction, TMG  tells NLB to hash based on the destination IP, which is again the client IP, so the packet will be handled by the same node as the original packet.

If the hook rule was not present , TMG would tell to use the default behavior (use the source IP), which would result in  calculating the hash based on the  source (server) IP, possibly yielding that a different node is supposed to handle the traffic, which is not what we want.

If  you have a TMG array with several nodes and NLB is enabled, then TMG service creates hook rules at start.

These rules can be checked by executing netsh tmg show nlb from an elevated command prompt, which yields similar output as can be seen below.

Notice the rules have a source and destination range, and a direction based on which TMG can decide what to tell NLB when its called: whether to hash on source (forward) or destination IP (reverse).

A potential problem occurs if hook rules are missing. In this post, we are going to explore a potential cause for missing hook rules.

The below is from a sample test lab which we built based on a particular issue we got reported by a customer:

In  the example above we can see only rules which were created and hash based on source (forward direction) for outgoing scenario. 

You however do not see any reverse rules, indicating that some rules may be missing .

I took those rules from my TMG Array with Internal 10.0.0.0/24, DMZ 192.168.0.0/24 and External 172.20.1.0/24 networks.

Let's imagine a scenario where we have created a publishing rule for a server from DMZ with a listener on External network and you have configured the rule to be half NAT (request appears from client).

Because there is no specific rule for the range external network -> DMZ, DMZ -> external, in both directions we use the default behavior to hash based on the source IP.

As described above, because the hook rule is missing, this may or may not work depending on client IP/published server twin. If the NLB hash algorithm gives the same NLB node ID for both the client and the server IP , it will work. Otherwise, client and server packets will be serviced by different hosts, and the published server responses will be dropped with   the  error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED.

The reason of the issue is lack of some NLB hook rules.

These rules are created at the startup based on network rules. In a real world scenario, when we may have a lot of subnets, it's quite easy to miss a network rule between two networks.

In this case, this is exactly what happened –  there was no network relationship defined between External and DMZ, hence the appropriate rule was never created

Once we add the network rule, the hook rules will be created. I created the rule from External to DMZ network with Route relationship. In the output below you can see how hook rules changed.

Now we have appropriate rules for processing requests from External to DMZ network back and forth, ensuring that we hash using the same IP in both directions. Hence, we should not get error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED any more.

If you see the above error, make sure to check whether the appropriate hook rules are present – one of the root causes for missing hook rules can be the missing network relationship definition.

Author:

Vasily Kobylin, Senior Support Engineer, Microsoft EMEA Forefront Edge

Reviewer:

Balint Toth, Senior Support Escalation Engineer, Microsoft EMEA Forefront Edge

Franck Heilmann, Senior Escalation Engineer, Microsoft EMEA Forefront Edge

Some of you may have already heard and know what NLB is and how it works as described in the general Network Load Balancing Overview [http://technet.microsoft.com/en-us/library/cc725946.aspx].

An integral part of a TMG NLB solution is Bi-direction affinity, which is well described at the following link:

Bi-Directional Affinity in ISA Server [http://blogs.technet.com/b/isablog/archive/2008/03/12/bi-directional-affinity-in-isa-server.aspx].

Bi-directional affinity creates multiple instances of Network Load Balancing (NLB) on the same host, which work in tandem to ensure that responses from published servers are routed through the appropriate ISA servers in a cluster. Bi-directional affinity is commonly used when NLB is configured with Internet Security and Acceleration (ISA) servers. If bi-directional affinity is not consistent across all NLB hosts or if NLB fails to initialize bi-directional affinity, the NLB cluster will remain in the converging state until a consistent teaming configuration is detected.

Bi-directional affinity is a crucial thing if you enable NLB on multiple interfaces, as it ensures a single client to work through the same node and have consistent data flow.

By default when a client connects to an NLB interface a hash algorithm based on the packet source IP (client) is computed in the NLB driver to decide which NLB node should handle this request. On the way back (the server responses to the client) the source IP is the server IP (not the client IP) and without BDA it may be handled by another TMG NLB node – which would discard the server response, not having seen the client request. Hence, a mechanism is needed to guarantee that client/server packets are handled by the same host in the array.

Bidirectional affinity ensures the server responses are handled by the same TMG NLB node as the original client request. The mechanism ensuring this functionality is implemented as  so-called hook rules:

http://technet.microsoft.com/en-us/library/dd348817(v=ws.10).aspx

Filter hooks help to direct traffic in a Network Load Balancing (NLB) cluster by filtering network packets. If the filter hooks are not properly configured, the NLB cluster will continue to converge and operate normally, however, the server application that is running with NLB will not be able to properly register the hooks.

The essential logic of the hook rules is the following:

At each packet, NLB calls out to the registered drivers (in this case fweng) whether they want to modify how the hash is created.

For example, when a client sends a SYN packet, NLB “asks” TMG’s fweng driver how it should calculate the hash. TMG will tell (depending on its hook rules) to use for example the client source IP for hashing (which is the default behavior). The calculated hash instructs NLB for example that the first node should handle the traffic and pass the SYN to the backend server.

When the server responds to the internal NLB of the TMG array, NLB calls out again to ask TMG how the hash is supposed to be calculated.

Based on the same hook rule set and seeing the packet direction, TMG  tells NLB to hash based on the destination IP, which is again the client IP, so the packet will be handled by the same node as the original packet.

If the hook rule was not present , TMG would tell to use the default behavior (use the source IP), which would result in  calculating the hash based on the  source (server) IP, possibly yielding that a different node is supposed to handle the traffic, which is not what we want.

If  you have a TMG array with several nodes and NLB is enabled, then TMG service creates hook rules at start.

These rules can be checked by executing netsh tmg show nlb from an elevated command prompt, which yields similar output as can be seen below.

Notice the rules have a source and destination range, and a direction based on which TMG can decide what to tell NLB when its called: whether to hash on source (forward) or destination IP (reverse).

A potential problem occurs if hook rules are missing. In this post, we are going to explore a potential cause for missing hook rules.

The below is from a sample test lab which we built based on a particular issue we got reported by a customer:

In  the example above we can see only rules which were created and hash based on source (forward direction) for outgoing scenario. 

You however do not see any reverse rules, indicating that some rules may be missing .

I took those rules from my TMG Array with Internal 10.0.0.0/24, DMZ 192.168.0.0/24 and External 172.20.1.0/24 networks.

Let's imagine a scenario where we have created a publishing rule for a server from DMZ with a listener on External network and you have configured the rule to be half NAT (request appears from client).

Because there is no specific rule for the range external network -> DMZ, DMZ -> external, in both directions we use the default behavior to hash based on the source IP.

As described above, because the hook rule is missing, this may or may not work depending on client IP/published server twin. If the NLB hash algorithm gives the same NLB node ID for both the client and the server IP , it will work. Otherwise, client and server packets will be serviced by different hosts, and the published server responses will be dropped with   the  error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED.

The reason of the issue is lack of some NLB hook rules.

These rules are created at the startup based on network rules. In a real world scenario, when we may have a lot of subnets, it's quite easy to miss a network rule between two networks.

In this case, this is exactly what happened –  there was no network relationship defined between External and DMZ, hence the appropriate rule was never created

Once we add the network rule, the hook rules will be created. I created the rule from External to DMZ network with Route relationship. In the output below you can see how hook rules changed.

Now we have appropriate rules for processing requests from External to DMZ network back and forth, ensuring that we hash using the same IP in both directions. Hence, we should not get error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED any more.

If you see the above error, make sure to check whether the appropriate hook rules are present – one of the root causes for missing hook rules can be the missing network relationship definition.

Author:

Vasily Kobylin, Senior Support Engineer, Microsoft EMEA Forefront Edge

Reviewer:

Balint Toth, Senior Support Escalation Engineer, Microsoft EMEA Forefront Edge

Franck Heilmann, Senior Escalation Engineer, Microsoft EMEA Forefront Edge

We are happy to announce the availability of Rollup 5 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2 (SP2). TMG SP2 Rollup 5 is available for download here: Rollup 5 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2

 

Please see KB Article ID: 2954173 for details of the fixes included in this rollup. The Build Number for this update is: 7.0.9193.644

 

To install this update, you must be running Forefront Threat Management Gateway 2010 Service Pack 2.

For more information about Forefront Threat Management Gateway 2010 SP2, please see the following
Microsoft website: Microsoft Forefront Threat Management Gateway 2010 Service Pack 2

Download information for Forefront TMG 2010 SP2

 

Thank you,

Forefront TMG Team

We are happy to announce the availability of Rollup 5 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2 (SP2). TMG SP2 Rollup 5 is available for download here: Rollup 5 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2

 

Please see KB Article ID: 2954173 for details of the fixes included in this rollup. The Build Number for this update is: 7.0.9193.644

 

To install this update, you must be running Forefront Threat Management Gateway 2010 Service Pack 2.

For more information about Forefront Threat Management Gateway 2010 SP2, please see the following
Microsoft website: Microsoft Forefront Threat Management Gateway 2010 Service Pack 2

Download information for Forefront TMG 2010 SP2

 

Thank you,

Forefront TMG Team

If some of you recently tried to publish RDP protocol through TMG server, and suddenly lost the possibility to perform TS connections to the TMG server itself, you may find this post useful!

In TMG 2010, a System Policy rule exists allowing RDP traffic from a white-list of workstations to the TMG server itself.

Thanks to this, it’s generically possible to connect to our TMG server from allowed PCs.

If you perform the following command, you’ll be able to see the TCP listener bound to the Remote Desktop Services (RDS) service accepting incoming RDP connections on default port 3389:

Netstat –ano | findstr :3389

Now, let’s assume that you have to publish RDP protocol externally through TMG, so that TS connections from external devices toward an internal server can be established, while the internal server’s IP address is masked.

You can do this by creating a specific “Non-Web server publishing rule” in TMG:

If you run again the netstat command mentioned above after you performed this configuration, you will see no differences at all, and everything should be working as expected.

Let’s now assume you have to reboot the TMG server.

After the reboot, if you run the netstat, you’ll see that the situation has changed:

Now the TMG server is listening for RDP connection only on the IP address which has been configured within TMG’s Server Publishing rule. Moreover, we can see that the listener is now associated to the PID of the FW service itself, and we no longer have entries related to the RDS service.

If you test TS connectivity to the TMG server from one of the allowed internal workstations, it will now fail.

This happens because of a socket conflict generated between the FW service and the RDS service, and it is an expected behavior.

In order to allow remote access while publishing RDP, basically 2 solutions exist: 

1. You can publish the RDP server on different port than 3389, using non web server publishing rule and creating a “customized” RDP protocol for the new considered port.

2. You can just change the RDS on the TMG to listen on a different port or adapter

 To apply this second solution, you can open Remote Desktop Session Host Configuration > Right-Click on RDP-TCP > Network Adapter > then select the internal NIC.

After this action, just restart the RDS service.

If you now run a new netstat, you’ll see the following situation:

You will now have the RDS service listening on the IP addresses bound to the internal NIC, while the FW service is listening on the external side for RDP publishing.

With this configuration, it’s again possible to establish TS connections to the TMG server even when the server publishes the RDP protocol.

As always…I hope you can find this useful!!

Author:

Daniele Gaiulli
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

If some of you recently tried to publish RDP protocol through TMG server, and suddenly lost the possibility to perform TS connections to the TMG server itself, you may find this post useful!

In TMG 2010, a System Policy rule exists allowing RDP traffic from a white-list of workstations to the TMG server itself.

Thanks to this, it’s generically possible to connect to our TMG server from allowed PCs.

If you perform the following command, you’ll be able to see the TCP listener bound to the Remote Desktop Services (RDS) service accepting incoming RDP connections on default port 3389:

Netstat –ano | findstr :3389

Now, let’s assume that you have to publish RDP protocol externally through TMG, so that TS connections from external devices toward an internal server can be established, while the internal server’s IP address is masked.

You can do this by creating a specific “Non-Web server publishing rule” in TMG:

If you run again the netstat command mentioned above after you performed this configuration, you will see no differences at all, and everything should be working as expected.

Let’s now assume you have to reboot the TMG server.

After the reboot, if you run the netstat, you’ll see that the situation has changed:

Now the TMG server is listening for RDP connection only on the IP address which has been configured within TMG’s Server Publishing rule. Moreover, we can see that the listener is now associated to the PID of the FW service itself, and we no longer have entries related to the RDS service.

If you test TS connectivity to the TMG server from one of the allowed internal workstations, it will now fail.

This happens because of a socket conflict generated between the FW service and the RDS service, and it is an expected behavior.

In order to allow remote access while publishing RDP, basically 2 solutions exist: 

1. You can publish the RDP server on different port than 3389, using non web server publishing rule and creating a “customized” RDP protocol for the new considered port.

2. You can just change the RDS on the TMG to listen on a different port or adapter

 To apply this second solution, you can open Remote Desktop Session Host Configuration > Right-Click on RDP-TCP > Network Adapter > then select the internal NIC.

After this action, just restart the RDS service.

If you now run a new netstat, you’ll see the following situation:

You will now have the RDS service listening on the IP addresses bound to the internal NIC, while the FW service is listening on the external side for RDP publishing.

With this configuration, it’s again possible to establish TS connections to the TMG server even when the server publishes the RDP protocol.

As always…I hope you can find this useful!!

Author:

Daniele Gaiulli
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

If some of you recently tried to publish RDP protocol through TMG server, and suddenly lost the possibility to perform TS connections to the TMG server itself, you may find this post useful!

In TMG 2010, a System Policy rule exists allowing RDP traffic from a white-list of workstations to the TMG server itself.

Thanks to this, it’s generically possible to connect to our TMG server from allowed PCs.

If you perform the following command, you’ll be able to see the TCP listener bound to the Remote Desktop Services (RDS) service accepting incoming RDP connections on default port 3389:

Netstat –ano | findstr :3389

Now, let’s assume that you have to publish RDP protocol externally through TMG, so that TS connections from external devices toward an internal server can be established, while the internal server’s IP address is masked.

You can do this by creating a specific “Non-Web server publishing rule” in TMG:

If you run again the netstat command mentioned above after you performed this configuration, you will see no differences at all, and everything should be working as expected.

Let’s now assume you have to reboot the TMG server.

After the reboot, if you run the netstat, you’ll see that the situation has changed:

Now the TMG server is listening for RDP connection only on the IP address which has been configured within TMG’s Server Publishing rule. Moreover, we can see that the listener is now associated to the PID of the FW service itself, and we no longer have entries related to the RDS service.

If you test TS connectivity to the TMG server from one of the allowed internal workstations, it will now fail.

This happens because of a socket conflict generated between the FW service and the RDS service, and it is an expected behavior.

In order to allow remote access while publishing RDP, basically 2 solutions exist: 

1. You can publish the RDP server on different port than 3389, using non web server publishing rule and creating a “customized” RDP protocol for the new considered port.

2. You can just change the RDS on the TMG to listen on a different port or adapter

 To apply this second solution, you can open Remote Desktop Session Host Configuration > Right-Click on RDP-TCP > Network Adapter > then select the internal NIC.

After this action, just restart the RDS service.

If you now run a new netstat, you’ll see the following situation:

You will now have the RDS service listening on the IP addresses bound to the internal NIC, while the FW service is listening on the external side for RDP publishing.

With this configuration, it’s again possible to establish TS connections to the TMG server even when the server publishes the RDP protocol.

As always…I hope you can find this useful!!

Author:

Daniele Gaiulli
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

If the Firewall service crashes a number of times within a short time period it does not automatically restart after the 4^th crash. If you review the Service Control Manager settings for the Firewall service appears to be configured to restart after all failures.

After each of the first three failures, you will see this error in the event log:

Log Name:      System
Source:        Service Control Manager
Date:          3/4/2013 1:36:24 PM
Event ID:      7031
Level:         Error
Computer:      TMG.domain.local
Description:
The Microsoft Forefront TMG Firewall service terminated unexpectedly.  It has done this 3 time(s).  The following corrective action will be taken in 60000 milliseconds: Restart the service.

This is inline with the expected behavior.

However, after the fourth failure the service will no longer restart and you will see this error in the event log:

Log Name:      System
Source:        Service Control Manager
Date:          3/4/2013 1:45:34 PM
Event ID:      7034
Level:         Error
Computer:      TMG.domain.local
Description:
The Microsoft Forefront TMG Firewall service terminated unexpectedly.  It has done this 4 time(s).

The behavior may appear inconsistent and unexpected but it is actually by design.

During the TMG installation, the service is configured to only automatically restart after the first 3 crashes in a 24 hour period in order to raise the attention of the system administrator that something is going wrong with this service that needs investigating. This can be considered similar to IIS Rapid Fail Protection to avoid a situation where we are restarting and then crashing straight way

By checking the service configuration in the registry key, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\fwsrv we can see the following:

The number of configured recovery actions is actually four, the first three being "Restart the service" and the fourth being "Do nothing", this results in the behavior described above.

The Windows Service Control Manager UI is limited to displaying only the first 3 actions and therefore gives the wrong impression of the configured actions.

If you have good reasons to configure the service to restart for subsequent failures you can do so by running the following command at an elevated command prompt:

Sc.exe failure fwsrv reset= 86400 actions= restart/60000/restart/60000/restart/60000

This configures 3 restart actions to restart the service after 60 seconds. The last action will be used to determine the behavior of subsequent crashes.

To revert to the default TMG behavior please run the following command from an elevated command prompt:-

Sc.exe failure fwsrv reset= 86400 actions= restart/60000/restart/60000/restart/60000//

This will re-configure Service Control Manager to restart the Firewall service for the first 3 crashes but to then take no action for the 4^th and subsequent crashes.

 

Author:

Gianni Bragante

Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Ian Parramore

Sr. Escalation Engineer – Microsoft Forefront Edge Security Team

If the Firewall service crashes a number of times within a short time period it does not automatically restart after the 4^th crash. If you review the Service Control Manager settings for the Firewall service appears to be configured to restart after all failures.

After each of the first three failures, you will see this error in the event log:

Log Name:      System
Source:        Service Control Manager
Date:          3/4/2013 1:36:24 PM
Event ID:      7031
Level:         Error
Computer:      TMG.domain.local
Description:
The Microsoft Forefront TMG Firewall service terminated unexpectedly.  It has done this 3 time(s).  The following corrective action will be taken in 60000 milliseconds: Restart the service.

This is inline with the expected behavior.

However, after the fourth failure the service will no longer restart and you will see this error in the event log:

Log Name:      System
Source:        Service Control Manager
Date:          3/4/2013 1:45:34 PM
Event ID:      7034
Level:         Error
Computer:      TMG.domain.local
Description:
The Microsoft Forefront TMG Firewall service terminated unexpectedly.  It has done this 4 time(s).

The behavior may appear inconsistent and unexpected but it is actually by design.

During the TMG installation, the service is configured to only automatically restart after the first 3 crashes in a 24 hour period in order to raise the attention of the system administrator that something is going wrong with this service that needs investigating. This can be considered similar to IIS Rapid Fail Protection to avoid a situation where we are restarting and then crashing straight way

By checking the service configuration in the registry key, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\fwsrv we can see the following:

The number of configured recovery actions is actually four, the first three being "Restart the service" and the fourth being "Do nothing", this results in the behavior described above.

The Windows Service Control Manager UI is limited to displaying only the first 3 actions and therefore gives the wrong impression of the configured actions.

If you have good reasons to configure the service to restart for subsequent failures you can do so by running the following command at an elevated command prompt:

Sc.exe failure fwsrv reset= 86400 actions= restart/60000/restart/60000/restart/60000

This configures 3 restart actions to restart the service after 60 seconds. The last action will be used to determine the behavior of subsequent crashes.

To revert to the default TMG behavior please run the following command from an elevated command prompt:-

Sc.exe failure fwsrv reset= 86400 actions= restart/60000/restart/60000/restart/60000//

This will re-configure Service Control Manager to restart the Firewall service for the first 3 crashes but to then take no action for the 4^th and subsequent crashes.

 

Author:

Gianni Bragante

Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Ian Parramore

Sr. Escalation Engineer – Microsoft Forefront Edge Security Team

If the Firewall service crashes a number of times within a short time period it does not automatically restart after the 4^th crash. If you review the Service Control Manager settings for the Firewall service appears to be configured to restart after all failures.

After each of the first three failures, you will see this error in the event log:

Log Name:      System
Source:        Service Control Manager
Date:          3/4/2013 1:36:24 PM
Event ID:      7031
Level:         Error
Computer:      TMG.domain.local
Description:
The Microsoft Forefront TMG Firewall service terminated unexpectedly.  It has done this 3 time(s).  The following corrective action will be taken in 60000 milliseconds: Restart the service.

This is inline with the expected behavior.

However, after the fourth failure the service will no longer restart and you will see this error in the event log:

Log Name:      System
Source:        Service Control Manager
Date:          3/4/2013 1:45:34 PM
Event ID:      7034
Level:         Error
Computer:      TMG.domain.local
Description:
The Microsoft Forefront TMG Firewall service terminated unexpectedly.  It has done this 4 time(s).

The behavior may appear inconsistent and unexpected but it is actually by design.

During the TMG installation, the service is configured to only automatically restart after the first 3 crashes in a 24 hour period in order to raise the attention of the system administrator that something is going wrong with this service that needs investigating. This can be considered similar to IIS Rapid Fail Protection to avoid a situation where we are restarting and then crashing straight way

By checking the service configuration in the registry key, HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesfwsrv we can see the following:

The number of configured recovery actions is actually four, the first three being "Restart the service" and the fourth being "Do nothing", this results in the behavior described above.

The Windows Service Control Manager UI is limited to displaying only the first 3 actions and therefore gives the wrong impression of the configured actions.

If you have good reasons to configure the service to restart for subsequent failures you can do so by running the following command at an elevated command prompt:

Sc.exe failure fwsrv reset= 86400 actions= restart/60000/restart/60000/restart/60000

This configures 3 restart actions to restart the service after 60 seconds. The last action will be used to determine the behavior of subsequent crashes.

To revert to the default TMG behavior please run the following command from an elevated command prompt:-

Sc.exe failure fwsrv reset= 86400 actions= restart/60000/restart/60000/restart/60000//

This will re-configure Service Control Manager to restart the Firewall service for the first 3 crashes but to then take no action for the 4^th and subsequent crashes.

 

Author:

Gianni Bragante

Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Ian Parramore

Sr. Escalation Engineer – Microsoft Forefront Edge Security Team

This post is about an issue I worked on several days ago.

Symptom:

========

My customer had a TMG array with two nodes running with NLB. The problem they faced was that from time to time some TMG node couldn’t process traffic anymore: requests to the virtual IP (VIP) failed and only rebooting the TMG machine eliminated the issue.

IE was configured to use the NLB virtual IP (VIP) as proxy address. When the issue happened users couldn’t browse internet pages -  the browser didn’t show any error page, it just stayed with a blank page.

Troubleshooting:

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

First of all, I looked at the TMG Web proxy log and found an  error logged there with the result code of 11001 (WSAHOST_NOT_FOUND) for  the request for  “contoso.com”, which we tried to browse in order to reproduce the issue.

Then I took a look at a captured network monitor trace in order to find an appropriate network conversation between the client and TMG:

    Time                             Delta time     Source           Destination        Protocol Length   Info

…

11:07:26.566261000  1.376436000    CLIENT_IP          TMG_VIP           HTTP     433    GET http://contoso.com/ HTTP/1.1

11:07:26.570933000  0.004672000    TMG_VIP           CLIENT_IP          HTTP     1440   HTTP/1.1 502 Proxy Error ( The host was not found. )  (text/html)

…

In a web proxy scenario, the web proxy is supposed to resolve the name, however, by some reason the node didn’t manage to resolve the remote host.

As the next step, I filtered out the trace for DNS traffic and didn’t find DNS packets on the node at all – this looked very suspicious.

Therefore I looked at Netstat and its output showed around ~62000 lines similar to the followings, whereas 2580 was the pid of wspsrv.exe:

…

  UDP    0.0.0.0:4002           *:*                                    2580

  UDP    0.0.0.0:4003           *:*                                    2580

  UDP    0.0.0.0:4004           *:*                                    2580

  UDP    0.0.0.0:4005           *:*                                    2580

  UDP    0.0.0.0:4006           *:*                                    2580

  UDP    0.0.0.0:4007           *:*                                    2580

  UDP    0.0.0.0:4020           *:*                                    2580

  UDP    0.0.0.0:4021           *:*                                    2580

  UDP    0.0.0.0:4022           *:*                                    2580

  UDP    0.0.0.0:4023           *:*                                    2580

  UDP    0.0.0.0:4024           *:*                                    2580

  UDP    0.0.0.0:4025           *:*                                    2580

  UDP    0.0.0.0:4026           *:*                                    2580

…

So TMG seemed to use up all UDP ports – hence there was no free UDP port left to use as source port for dns queries. This explained why name resolution failed and why TMG returned 502.

Why was such a great amount of ports used by TMG?

My guess was that it might be doing it on behalf of a client. Therefore, I looked at the Firewall log which showed that there were huge amount of UDP requests from a single client to different external hosts.

Luckily TMG firewall client was installed on the client machine which gave us an application name:

…

7:27:51 Establish CLINET2_IP 2058 EXTERNAL_HOST_1 54150 0x0 Access Internet UDP domain\user smax4pnp.exe:3:5.1 TMG1 Unidentified IP Traffic

7:27:52 Establish CLINET2_IP 2033 EXTERNAL_HOST_2 9362 0x0 Access Internet UDP domain\user smax4pnp.exe:3:5.1 TMG1 Unidentified IP Traffic

7:27:53 Terminate CLINET2_IP 2026 EXTERNAL_HOST_3 59866 0x80074e20 Access Internet UDP domain\user smax4pnp.exe:3:5.1 TMG1 Unidentified IP Traffic

…

So TMG used up all the available ports due to the excessive amount of request from this  client/application.

In order to resolve the issue the customer disabled the client  that has  been causing this huge UDP traffic.

 

Author:

Vasily Kobylin, Senior Support Engineer, EMEA Forefront Edge Team

 

Reviewer:

Balint Toth, Senior Support Escalation Engineer, EMEA Forefront Edge Team

This post is about an issue I worked on several days ago.

Symptom:

========

My customer had a TMG array with two nodes running with NLB. The problem they faced was that from time to time some TMG node couldn’t process traffic anymore: requests to the virtual IP (VIP) failed and only rebooting the TMG machine eliminated the issue.

IE was configured to use the NLB virtual IP (VIP) as proxy address. When the issue happened users couldn’t browse internet pages -  the browser didn’t show any error page, it just stayed with a blank page.

Troubleshooting:

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

First of all, I looked at the TMG Web proxy log and found an  error logged there with the result code of 11001 (WSAHOST_NOT_FOUND) for  the request for  “contoso.com”, which we tried to browse in order to reproduce the issue.

Then I took a look at a captured network monitor trace in order to find an appropriate network conversation between the client and TMG:

    Time                             Delta time     Source           Destination        Protocol Length   Info

…

11:07:26.566261000  1.376436000    CLIENT_IP          TMG_VIP           HTTP     433    GET http://contoso.com/ HTTP/1.1

11:07:26.570933000  0.004672000    TMG_VIP           CLIENT_IP          HTTP     1440   HTTP/1.1 502 Proxy Error ( The host was not found. )  (text/html)

…

In a web proxy scenario, the web proxy is supposed to resolve the name, however, by some reason the node didn’t manage to resolve the remote host.

As the next step, I filtered out the trace for DNS traffic and didn’t find DNS packets on the node at all – this looked very suspicious.

Therefore I looked at Netstat and its output showed around ~62000 lines similar to the followings, whereas 2580 was the pid of wspsrv.exe:

…

  UDP    0.0.0.0:4002           *:*                                    2580

  UDP    0.0.0.0:4003           *:*                                    2580

  UDP    0.0.0.0:4004           *:*                                    2580

  UDP    0.0.0.0:4005           *:*                                    2580

  UDP    0.0.0.0:4006           *:*                                    2580

  UDP    0.0.0.0:4007           *:*                                    2580

  UDP    0.0.0.0:4020           *:*                                    2580

  UDP    0.0.0.0:4021           *:*                                    2580

  UDP    0.0.0.0:4022           *:*                                    2580

  UDP    0.0.0.0:4023           *:*                                    2580

  UDP    0.0.0.0:4024           *:*                                    2580

  UDP    0.0.0.0:4025           *:*                                    2580

  UDP    0.0.0.0:4026           *:*                                    2580

…

So TMG seemed to use up all UDP ports – hence there was no free UDP port left to use as source port for dns queries. This explained why name resolution failed and why TMG returned 502.

Why was such a great amount of ports used by TMG?

My guess was that it might be doing it on behalf of a client. Therefore, I looked at the Firewall log which showed that there were huge amount of UDP requests from a single client to different external hosts.

Luckily TMG firewall client was installed on the client machine which gave us an application name:

…

7:27:51 Establish CLINET2_IP 2058 EXTERNAL_HOST_1 54150 0x0 Access Internet UDP domainuser smax4pnp.exe:3:5.1 TMG1 Unidentified IP Traffic

7:27:52 Establish CLINET2_IP 2033 EXTERNAL_HOST_2 9362 0x0 Access Internet UDP domainuser smax4pnp.exe:3:5.1 TMG1 Unidentified IP Traffic

7:27:53 Terminate CLINET2_IP 2026 EXTERNAL_HOST_3 59866 0x80074e20 Access Internet UDP domainuser smax4pnp.exe:3:5.1 TMG1 Unidentified IP Traffic

…

So TMG used up all the available ports due to the excessive amount of request from this  client/application.

In order to resolve the issue the customer disabled the client  that has  been causing this huge UDP traffic.

 

Author:

Vasily Kobylin, Senior Support Engineer, EMEA Forefront Edge Team

 

Reviewer:

Balint Toth, Senior Support Escalation Engineer, EMEA Forefront Edge Team

This post is about an issue I worked on several days ago.

Symptom:

========

My customer had a TMG array with two nodes running with NLB. The problem they faced was that from time to time some TMG node couldn’t process traffic anymore: requests to the virtual IP (VIP) failed and only rebooting the TMG machine eliminated the issue.

IE was configured to use the NLB virtual IP (VIP) as proxy address. When the issue happened users couldn’t browse internet pages -  the browser didn’t show any error page, it just stayed with a blank page.

Troubleshooting:

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

First of all, I looked at the TMG Web proxy log and found an  error logged there with the result code of 11001 (WSAHOST_NOT_FOUND) for  the request for  “contoso.com”, which we tried to browse in order to reproduce the issue.

Then I took a look at a captured network monitor trace in order to find an appropriate network conversation between the client and TMG:

    Time                             Delta time     Source           Destination        Protocol Length   Info

…

11:07:26.566261000  1.376436000    CLIENT_IP          TMG_VIP           HTTP     433    GET http://contoso.com/ HTTP/1.1

11:07:26.570933000  0.004672000    TMG_VIP           CLIENT_IP          HTTP     1440   HTTP/1.1 502 Proxy Error ( The host was not found. )  (text/html)

…

In a web proxy scenario, the web proxy is supposed to resolve the name, however, by some reason the node didn’t manage to resolve the remote host.

As the next step, I filtered out the trace for DNS traffic and didn’t find DNS packets on the node at all – this looked very suspicious.

Therefore I looked at Netstat and its output showed around ~62000 lines similar to the followings, whereas 2580 was the pid of wspsrv.exe:

…

  UDP    0.0.0.0:4002           *:*                                    2580

  UDP    0.0.0.0:4003           *:*                                    2580

  UDP    0.0.0.0:4004           *:*                                    2580

  UDP    0.0.0.0:4005           *:*                                    2580

  UDP    0.0.0.0:4006           *:*                                    2580

  UDP    0.0.0.0:4007           *:*                                    2580

  UDP    0.0.0.0:4020           *:*                                    2580

  UDP    0.0.0.0:4021           *:*                                    2580

  UDP    0.0.0.0:4022           *:*                                    2580

  UDP    0.0.0.0:4023           *:*                                    2580

  UDP    0.0.0.0:4024           *:*                                    2580

  UDP    0.0.0.0:4025           *:*                                    2580

  UDP    0.0.0.0:4026           *:*                                    2580

…

So TMG seemed to use up all UDP ports – hence there was no free UDP port left to use as source port for dns queries. This explained why name resolution failed and why TMG returned 502.

Why was such a great amount of ports used by TMG?

My guess was that it might be doing it on behalf of a client. Therefore, I looked at the Firewall log which showed that there were huge amount of UDP requests from a single client to different external hosts.

Luckily TMG firewall client was installed on the client machine which gave us an application name:

…

7:27:51 Establish CLINET2_IP 2058 EXTERNAL_HOST_1 54150 0x0 Access Internet UDP domain\user smax4pnp.exe:3:5.1 TMG1 Unidentified IP Traffic

7:27:52 Establish CLINET2_IP 2033 EXTERNAL_HOST_2 9362 0x0 Access Internet UDP domain\user smax4pnp.exe:3:5.1 TMG1 Unidentified IP Traffic

7:27:53 Terminate CLINET2_IP 2026 EXTERNAL_HOST_3 59866 0x80074e20 Access Internet UDP domain\user smax4pnp.exe:3:5.1 TMG1 Unidentified IP Traffic

…

So TMG used up all the available ports due to the excessive amount of request from this  client/application.

In order to resolve the issue the customer disabled the client  that has  been causing this huge UDP traffic.

 

Author:

Vasily Kobylin, Senior Support Engineer, EMEA Forefront Edge Team

 

Reviewer:

Balint Toth, Senior Support Escalation Engineer, EMEA Forefront Edge Team

One of the features introduced with TMG Service Pack 2 is to run the Firewall Service with a Domain account, this allow users to authenticate with Kerberos when using NLB.
Find more information about this feature here: http://technet.microsoft.com/en-us/library/hh454304.aspx

However you should pay attention when specifying the account name to avoid problems with logging to SQL Server, either local or remote.

The account specified is used by TMG to configure the service and also to create the Login in SQL Server.
For the TMG Firewall service to start any format is fine, but for SQL Server only the format domainName\loginName is valid.

For example if you want to use the account TMGSvc in the domain CONTOSO you have to enter CONTOSO\TMGSvc.

Using the UPN (User Principal Name) format or the FQDN (Fully Qualified Domain Name) does not work.
For example you cannot use TMGSvc@Contoso.com or Contoso.com\TMGSvc

The SQL Server documentation for the CREATE LOGIN command has the following note:

"When you are creating logins that are mapped from a Windows domain account, you must use the pre-Windows 2000 user logon name in the format [<domainName>\<loginName>]."

If you try using an invalid format you will see the Log Status as Disconnected and your LLQ folder growing:

 

Author:
Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:
Lars Bentzen
Sr. Escalation Engineer – Microsoft Forefront Edge Security Team

One of the features introduced with TMG Service Pack 2 is to run the Firewall Service with a Domain account, this allow users to authenticate with Kerberos when using NLB.
Find more information about this feature here: http://technet.microsoft.com/en-us/library/hh454304.aspx

However you should pay attention when specifying the account name to avoid problems with logging to SQL Server, either local or remote.

The account specified is used by TMG to configure the service and also to create the Login in SQL Server.
For the TMG Firewall service to start any format is fine, but for SQL Server only the format domainNameloginName is valid.

For example if you want to use the account TMGSvc in the domain CONTOSO you have to enter CONTOSOTMGSvc.

Using the UPN (User Principal Name) format or the FQDN (Fully Qualified Domain Name) does not work.
For example you cannot use TMGSvc@Contoso.com or Contoso.comTMGSvc

The SQL Server documentation for the CREATE LOGIN command has the following note:

"When you are creating logins that are mapped from a Windows domain account, you must use the pre-Windows 2000 user logon name in the format [<domainName><loginName>]."

If you try using an invalid format you will see the Log Status as Disconnected and your LLQ folder growing:

 

Author:
Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:
Lars Bentzen
Sr. Escalation Engineer – Microsoft Forefront Edge Security Team

One of the features introduced with TMG Service Pack 2 is to run the Firewall Service with a Domain account, this allow users to authenticate with Kerberos when using NLB.
Find more information about this feature here: http://technet.microsoft.com/en-us/library/hh454304.aspx

However you should pay attention when specifying the account name to avoid problems with logging to SQL Server, either local or remote.

The account specified is used by TMG to configure the service and also to create the Login in SQL Server.
For the TMG Firewall service to start any format is fine, but for SQL Server only the format domainName\loginName is valid.

For example if you want to use the account TMGSvc in the domain CONTOSO you have to enter CONTOSO\TMGSvc.

Using the UPN (User Principal Name) format or the FQDN (Fully Qualified Domain Name) does not work.
For example you cannot use TMGSvc@Contoso.com or Contoso.com\TMGSvc

The SQL Server documentation for the CREATE LOGIN command has the following note:

"When you are creating logins that are mapped from a Windows domain account, you must use the pre-Windows 2000 user logon name in the format [<domainName>\<loginName>]."

If you try using an invalid format you will see the Log Status as Disconnected and your LLQ folder growing:

 

Author:
Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:
Lars Bentzen
Sr. Escalation Engineer – Microsoft Forefront Edge Security Team