3

I have an issue where websites that are hosted on a web server (www.example.com) are not accessible from their own network when accessed via its public IP address, but they are accessible from every other network.

This is the network setup:

enter image description here

I have a TMG 2010 SP1 machine behind a router that's managed by someone else (that I have no access to), and behind that router is the internet.

The "external network" router has a 1:1 NAT for IP addresses pointing to corresponding private IP addresses on the TMG box. The TMG Edge then has a web proxy rule that forwards the requests (to www.example.com) to a web server on Network B.

When you try to access www.example.com (that is hosted on Network B) via its public IP address, the following happens:

Internet -  HTTP 200 OK
External -  HTTP 200 OK
Network A - HTTP 200 OK
Network B - Error Code 10060: Connection timeout
Network C - HTTP 200 OK

I see the traffic hit the TMG firewall, but then it seems to get lost. It does not forward the packet to the external network (which, if it did, it would send straight back). Wireshark shows the packet coming in on the Network B interface, but it never leaves the TMG.

After requesting http://www.example.com/ The TMG firewall log shows an initial permitted outbound request, followed 60 seconds later by:

  • Failed Connection Attempt
  • Source Network: Network B
  • Destination Network: External
  • URL: http://203.206.238.xxx (the public IP address, not the URL I actually requested)

Status: 10060 A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

I have no idea where the problem lies. I don't know if it's because for some reason it's proxying the public IP address as the URL (there is proxy rules for the IP address, only for FQDNs), or if it's something completely else.

Mark Henderson
  • 68,316
  • 31
  • 175
  • 255
  • I don't know TMG at all, but making a request that has to go back out the interface it came in on is prohibited by a lot of firewalls (PIX, ASA, Linux unless you disable reverse path filtering). I'd research reverse path filtering. – polynomial Oct 01 '11 at 21:02
  • Yes, I had that issue with a PFSense firewall using NAT one day (they called it NAT Reflection) but I've no idea what it would be called on TMG, or if it even applies :( – Mark Henderson Oct 02 '11 at 07:56
  • Where are the DNS servers with regard to each network? So the 1:1 Nat for your webserver is occurring on the "external network" and not on TMG? – GregD Oct 02 '11 at 16:28
  • @GregD - the DNS servers are inside Network B. Correct, the 1:1 NAT is on the external network. I'm asking them to route the public IPs to us rather than 1:1 NAT, but I don't know how long that's going to take – Mark Henderson Oct 02 '11 at 22:31

2 Answers2

3

I'm pretty sure this has to do with the way TMG is designed. According to:

http://technet.microsoft.com/en-us/library/cc995133.aspx

Bypassing Forefront TMG for firewall client requests

Microsoft Forefront Threat Management Gateway is designed to handle communications between different networks. Usually, clients on a specific network should not traverse Forefront TMG to reach hosts located in the same network. Instead, direct access should be used.

Direct access enables Firewall client computers to do the following: Bypass the Microsoft Firewall Client configuration and connect directly to resources. Make Web proxy requests that bypass the Web proxy filter.

This allows Firewall clients to access resources located in their local network without going through Forefront TMG and allows clients to make Web requests without going through Forefront TMG as a proxy.

This also covers significant limitations of TMG in a 'single adapter setup' which is similar to how B would connect to the web server:

http://technet.microsoft.com/en-us/library/cc995236.aspx

polynomial
  • 3,968
  • 13
  • 24
  • Oh, nice. It's a public holiday here today, so I'll try this when I go back into the office tomorrow – Mark Henderson Oct 02 '11 at 22:32
  • I looked into the implications of setting the network up the way TMG suggests, and decided that it was going to introduce more issues than it solves. The workaround is to use TMG as a proxy instead of SecureNAT. Because there's not many machines on Network B, I have just set up their proxies and that seems to work. – Mark Henderson Oct 05 '11 at 03:26
0

Two things come to mind:

  • The publishing rule on the TMG is not able to resolve the name of internal server name of the hosting server. Firewall Policy >> Properties >> To >> 2nd Text field about Computer name or IP address.
  • The web host expects the full URL and not the internal name (Same location, next check box)

Anything on the webserver logs?

SBWorks
  • 289
  • 1
  • 3
  • 12
  • There is an internal IP to fallback on in the proxy settings, and nothing in the web server logs. The web host definately expects a full URL, not an IP address, but if it was expecting an IP address, it is listening on a `192.168` address (hence the proxy) :( Any other ideas? – Mark Henderson Sep 30 '11 at 08:45
  • Is the information on the "Public Name" tab Correct? And if you enable the "Forward the original host header instead of the actual one" does that change anything? – SBWorks Oct 03 '11 at 01:59