Wednesday, February 13, 2013 8:58 AM
We are using TMG 2010 as web proxy server. The problem is only related to certain search sites. Here are some examples:
The error message we are getting appears when a search is performed on the site:
- Error Code 64: Host not available
- Background: The gateway or proxy server lost connection to the Web server.
- Date: 2013-02-13 08:39:54 [GMT]
- Server: server.domain.com
- Source: Remote server
I get a failed connection Attempt in the TMG log:
Log type: Web Proxy (Forward)
Status: 64 The specified network name is no longer available.
Rule: Allowed Websites everyone
Source: Internal (ipipipip:57753)
Destination: Internal (22.214.171.124:80)
Request: GET http://www.krak.dk/query=what=all&search_word=test&geo:area=&btn_all=S%C3&B8g
Filter Information: Req ID: 113333b2
I believe above "Destination" stated as Internal might be a problem?? Seems like these sites build on the same backbone. Since I get the same IP from both sites in the GET. Some sort of load balancing issue maybe?
I read this post: ISA forum thread and ruled out that the registry value "EnablePMTUDiscovery" was involved as it already is enabled (1).
Please give me some advice on this one.
Wednesday, February 13, 2013 9:54 AM
As you yourself question the destination of "Internal" I need to ask if this is a single NIC TMG acting as a proxy or if it is a 2+ NIC TMG acting as a firewall.
If it is a single NIC TMG then the destination of Internal is expected as TMG in that case sees everything as internal. If it isn't, then you have an issue with your network defintitions.
This needs to verified first.
Hth, Anders Janson Enfo Zipper
- Marked As Answer by Nick Gu - MSFTMicrosoft Contingent Staff, Moderator Monday, February 18, 2013 2:43 PM
- Unmarked As Answer by Joakim Bergquist Monday, March 11, 2013 7:48 AM
Thursday, February 21, 2013 7:16 AM
Thursday, February 21, 2013 11:19 AM
Sorry for not 'answering' your question - as I read it it wasn't an answer. However, a thread that is left idle will be marked as answered regardless of status by the forum moderator (Nick in this case).
Now for your issue.
To be quite honest, you'll most likely won't get an exact answer on this issue through the forums. Why? This issue is not a TMG issue in my opinion (unless there's something funky in the HTTP policy). As the link you reference says, the issue is upstream from your TMG. Taking TMG may remove the issue but the reason for that is TMG is very strict in how it handles traffic according to standards.
Do note that the below steps implies a repeat'n'rinse approach at certains steps - you'll understand where. What I would do is the following:
- TMG is up to date (SP2 RU3)
- Nic drivers are up to date, especially important if your nic's are based on Broadcom chipset as for instance most HP nics are
- That you have nothing funky configured in the HTTP policy for the rule allowing the traffic (URL/Query length etc). This should really not be an issue as you would get a reasonably clear error code if that was the case, but double-check for good measure.
2. Download TMG Best Practices Analyzer (BPA) from ms.com and install it on the TMG server
3. Run BPA and generate a complete report. Investigate and address any issues that the BPA flags
4. Run TMG Data Packager (TDP, installed as a part of the BPA) and run a repro using the Web Proxy scenario. Follow the instructions and reproduce the problem. Be prepared when you run the repro, having it running longer than necessary will generate lots of data that will just crowd your vision.
5. If possible, run Network Monitor on a client that is not connecting through TMG (another network or whatever, find a client where it works).
6. Examine the data generated by the TDP. Focus on the web proxy log and the Netmons generated. Look for network anomalies (MTU, retransmits etc etc).
7. Compare with Netmons generated from a working client. Look for differences in how the TCP connection functions (MTU, retransmits etc etc)
8. If nothing obvious, try setting the MTU to something small, like 576 bytes.
9. Change the query string in order to find where it stops working and compare a maxed out functioning trace with a failing trace. You want to know what changes when doing so and where the limit is in order to understand what the actual problem.
10. If all this doesn't get you anywhere you need to find someone that can assist you 'hands on'.
Hth, Anders Janson Enfo Zipper