HTTPS Reverse Proxy on IIS 10 – External Access Fails (Timeout) Although Local Requests Work

Hello Cenk,

Thanks for sharing the details of your setup. Based on what you described, everything inside the server (your IIS + ARR + URL Rewrite setup) seems to be working fine, because your Invoke-WebRequest from the server itself succeeds with a 200.

However, the fact that external clients time out and you don’t see any entries in the IIS log for those external requests is a strong sign that the problem isn’t the proxy logic, but rather traffic not reaching the box at all. In short: the issue is likely network/firewall/NAT related.

Please check for these:

1. Server firewall and network profile
   • On your server, check which network profile is active (Domain, Private, Public).
   • Make sure there is an inbound rule allowing TCP port 443 on all profiles, or temporarily disable the firewall to test if external access then works.
2. External reachability of port 443
   • From a machine outside your internal network, run:

     
          nslookup lojistik.abc.com.tr  
     
          Test-NetConnection -ComputerName lojistik.abc.com.tr -Port 443
     
     

   • If this fails (times out or “connection refused”), it means traffic isn’t being routed from the internet to your server.
3. NAT / edge firewall / port forwarding
   • Since your server IP is 10.6.130.90 (private), ensure your external/public IP (which your domain resolves to) has port 443 forwarded to that internal IP.
   • Check there’s no firewall on the perimeter blocking HTTPS traffic.
4. Binding in IIS
   • In IIS Manager, verify your HTTPS binding: IP address should ideally be “All Unassigned” or the external-facing IP; port 443; correct SSL certificate.
   • On the server run netstat -ano | findstr :443, look for 0.0.0.0:443 (listening on all interfaces) rather than 127.0.0.1:443.

If after you check these things it still doesn’t work, please post the results of your external Test-NetConnection .

For reference, here’s Microsoft’s official guide on using IIS with ARR as a reverse proxy: https://learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing

Hope this helps.

lojistik.abc.com.tr should be the ipaddress of the iis server. This appears correct. The clients need to be on the same network or have routing to this ipaddress. Use ping to check.

Hello Cenk,

your own analysis is basically spot on;

If it works from the server itself, but external clients time out and you see nothing in the IIS logs that almost always means the traffic never reaches IIS. So the problem isn’t in the reverse proxy rule or ARR, it’s somewhere in the network path before the request hits the web server.

I’d walk through it like this:

1. Double-check Windows Firewall on the server

Seeing port 443 as "listening" in "netstat" is good but not enough...you still need an inbound firewall rule that actually allows it.

On the server:

# See if there is any active inbound rule for port 443
Get-NetFirewallRule |
  Where-Object { $_.Enabled -eq 'True' -and $_.Direction -eq 'Inbound' } |
  Get-NetFirewallPortFilter |
  Where-Object { $_.LocalPort -eq 443 }

If nothing shows up, add a simple allow rule for testing:

New-NetFirewallRule -DisplayName "HTTPS Inbound" `
  -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

This is much safer than just turning the whole firewall off.

2. From a client, test raw TCP connectivity to 443

From another machine (same network / segment if possible):

Test-NetConnection -ComputerName lojistik.abc.com.tr -Port 443
# or
Test-NetConnection -ComputerName 10.6.130.90 -Port 443

or old school:

telnet lojistik.abc.com.tr 443

If this already times out or "TcpTestSucceeded = False", then you know for sure the problem is before IIS, on the network path.

3. 10.6.130.90 is a private IP => check NAT / perimeter firewall

10.6.130.90 is a private address, so the server is almost certainly sitting inside an internal/DMZ network. From outside or from other segments, the flow probably looks like:

client => firewall / load balancer =>10.6.130.90:443

You’ll want to verify..

• that there is actually a 443 NAT/port-forward rule pointing to 10.6.130.90:443,

and that the firewall rule allows 443 inbound from the client networks you’re testing from.

The fact that Invoke-WebRequest "https://lojistik.abc.com.tr/LMYS/login" from the server itself returns 200 only proves that IIS + SSL binding + ARR + backend are fine. It doesn’t prove that the perimeter firewall/edge config is correct - you might be hitting it locally or via hairpin NAT while external traffic is dropped.

At this point, asking the network team "do you see inbound 443 traffic for lojistik.abc.com.tr in the firewall logs, and where is it being NAT’ed to?" is usually the quickest way forward.

4. IIS side just as a sanity check

Given the local 200 response, your bindings are probably fine, but to be complete:

In IIS Site Bindings for https:

• IP: All Unassigned or explicitly 10.6.130.90
• Host name: lojistik.abc.com.tr
• Correct certificate selected

Since you already get 200 from the server using the same host name, this part is likely correct. The real red flag is, no IIS log entries at all for external attempts - that’s almost always "network is dropping the packets".

bottom line:

• Local 200 from the server => IIS/SSL/ARR/backend are basically configured correctly.
• External timeout + empty IIS logs => HTTPS traffic never reaches IIS; the problem is in Windows Firewall / NAT / perimeter firewall, not in your reverse proxy rule.

So the next key data point is, Test-NetConnection lojistik.abc.com.tr -Port 443 from a client, and what the firewall logs say about inbound 443. Once you see that traffic actually hitting the server, IIS will start logging it and then any remaining ARR tweaks are easy to sort out.