TMG 2010 rewriting original host headers when told not to

 TMG 2010 rewriting original host headers when told not to

I found a strange behavior with TMG 2010 when publishing a website. It appears to rewrite URLs sent outbound to clients when the "send original host header is sent" under certain conditions. Here are those conditions:

  • The published site is on both http and https (each protocol bridged to its' respective port)
  • Some type of URL is sent to the client that while within the original host header context, is a change between HTTP  -->  HTTPS
  • Public URL is www.sitename.com (resolves to two IP addresses for redundancy, each correlating to redundant TMG servers)
  • Also have www1.sitename.com and www2.sitename.com (each of those for one of the two redundant TMG firewall/proxy servers)
  • The "internal site name" in TMG is just using IP address, and because you must use a site name, I used the external main URL www.sitename.com
  • Checked flag for "send original host header..." (*should* not alter headers in any way)
  • Checked the box to set traffic to appear to originate from TMG (NAT)
  • None of the bridging protocol redirection or URL redirection features are on (just passing http & https straight through)
  • Internal IIS site is not configured with host headers, will work on any URL given to it

Here is precisely what I encountered:

  1. Client originates a session to http://www.sitename.com and this works
  2. Client fills out form on site which redirects to https://www.sitename.com (not relative, exact URL, done in ASPX on the web server)
  3. Client browser instead is redirected to http://www.sitename.com (no https); this basically means that TMG blocks redirects initiated by the web server when the internal site name matches the external site name.
  4. Verified by testing without TMG that this functionality works fine
  5. Going directly to the https://www.sitename.com URL works fine
  6. Going to either of the alternate URLs work fine with either http/https and www1/www2
  7. The redirect form works properly for the alternate URLs, but not for the main URL

So by process of elimination I found that this appears to be TMG not affecting any host header inbound, nor affecting the alternate URLs outbound.This appears to affect only the main URL outbound, as TMG appears to be rewriting the protocol part of the header when the submitted form returns a redirect from http to https (changing https back to http).

 

Fixes: Uncheck the "send original host header..." flag and all functionality works correctly. I don't think this is as "clean", because it means that TMG touches every request and changes the host header to the internal host header, however on the IIS bright-side this means the web server will see the same host header no matter what clients request (normalization). The only caveat is that if you wanted to use an internal URL (instead of IP address) for the site that was the same as the external URL it would either not work, or would require a DNS trick on TMG to force it. Or, you could just change the internal URL to something else (not used).

 

TMG proxy background:

    This isn't so much of a bug in TMG as a "feature". TMG is designed to allow external access to internal resources. I've found that it makes a powerful and flexible reverse proxy server, you just have to contend with a few "features". TMG's basic design-premise is based on rewriting URLs that are normally only internally visible, to URLs that are externally visible. This means that TMG errs towards the side of rewriting in exception cases, which this appears to be. This methodology appears to assume that the web servers are dumb, and don't know about external URLs. This premise is fine, except when it is necessary for the web server to perform some type of functionality that requires a complex redirect based on a user action (such as switching to https when a user logs in). TMG assumes that the redirect is internal in nature and blocks the redirect in favor of maintaining the original URL and same-protocol bridging (or more accurately not bridging). This appears to only be an issue when TMG is confused by using the external URL as the internal URL (same as listener and client requests). This shouldn't be an issue when you specify that TMG uses an IP address for the internal site, however it appears that MS has designed TMG to be "smarter" and "more helpful" by performing host header translation outbound, even when you request it no to do so...