We have an IIS website hosted on a server in a DMZ. External users can access it normally, and internal DNS is configured with split-horizon DNS so the site name resolves to the server's internal IP. The firewall allows HTTPS traffic, and connecting directly to the internal IP from inside works.
However, internal users get a timeout when browsing to the site by its DNS name. The DNS lookup returns the expected internal address, and the IIS bindings use a wildcard host name. The site also works when tested with curl while forcing the hostname and internal IP together:
curl -vk --resolve website.company.com:443:10.90.1.12 https://website.company.com/
That test connects successfully and returns an HTTP 302 response from IIS. What could cause normal browser requests using the DNS name to time out when direct-IP access and the forced curl test both work?
3 Answers
A wildcard IIS binding does not rule out all hostname issues, especially with HTTPS. Verify that the site has an HTTPS binding on port 443 and that the certificate/SNI configuration matches the hostname. However, a binding problem would normally produce a certificate error, HTTP error, or connection response—not a pure timeout—so I would investigate DNS and the firewall path first.
Check the IIS logs and firewall logs at the exact time of an internal attempt. If there is no IIS log entry, the request is not reaching IIS.
Another option is to use the external address internally through a firewall hairpin or loopback NAT, but that is usually unnecessary when direct LAN-to-DMZ routing works. If internal DNS returns the private address, confirm that the firewall permits traffic from the specific client subnet to that address on TCP 443 and that the DMZ server’s return route points back through the correct gateway.
The successful --resolve test suggests the route and server are fine from at least that client, so compare the browser’s proxy settings and DNS behavior with the curl test before changing the NAT design.
The curl result is an important clue: IIS, the HTTPS binding, SNI, and the internal route are working. Since --resolve forces the intended IP while still sending the real hostname, the failure is probably happening before the request reaches IIS.
Check the actual connection the browser is making. Look for an unexpected AAAA record, a stale DNS result, a configured proxy, secure DNS, or a cached public address. From the affected machine, compare nslookup or Resolve-DnsName results with the address shown in the browser’s network tools. Also try curl without --resolve and use curl -4 and curl -6 separately.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures