I have an IIS website hosted on a DMZ server. Split-brain DNS is configured so internal clients resolve website.company.com to the server's internal IP, while external users reach it through the public address and NAT. The DNS lookup returns the expected internal IP, firewall rules allow HTTPS, and browsing directly to the internal IP works. However, accessing the site by its DNS name from inside the building simply times out. The same hostname works normally from outside the network. IIS bindings are set broadly, and a curl request that forces the hostname to the internal IP successfully connects and receives an HTTP 302 response. What should I check next to determine why normal browser requests time out?
3 Answers
Test from an affected client with the browser developer tools or curl and confirm the actual destination address. Secure DNS, cached browser DNS, an old hosts entry, a proxy, or an internal AAAA record can cause the browser to use a different address than the one returned by your internal A record. Flush the client and browser DNS caches, check both A and AAAA records, and temporarily bypass the proxy if one is configured.
Another possibility is the firewall path. If internal DNS points to the DMZ address, make sure the LAN-to-DMZ rule permits that exact destination and that return traffic is routed correctly. Alternatively, resolve the internal name to the public address and configure NAT loopback or hairpin NAT, but that is a firewall design change rather than an IIS fix. Direct LAN-to-DMZ routing is usually simpler if it is supported and consistently allowed.
There is direct routing from the LAN to the DMZ and HTTPS rules are in place. Hairpin NAT may be an option, but I’m first checking why the normal hostname request behaves differently from the forced curl request.
Look at the network path rather than assuming IIS is the cause. Since the internal IP works directly and the forced-hostname curl request succeeds, the web server, TLS negotiation, and hostname binding are responding correctly. Compare a normal curl request with the forced one, inspect the IIS logs and firewall session logs, and verify whether the normal request is being sent to the same IP. If the normal request never appears in IIS logs, it is being blocked or routed elsewhere before reaching the server.
Some browsers keep their own DNS and connection caches after a laptop changes networks, so checking the browser’s DNS cache and testing with another browser or a fresh client can help isolate that.