Port forward HTTPS on 443 to IIS server doesn't work
April 30, 2011 5:06 AM Subscribe
An IIS web server won't respond to port forwarded requests from the world on 443, but will reply to port forwarded requests on port 80. The IIS web server will answer on 80 and 443 on the LAN. I tried a new router, as well.
I have been helping a local non-profit, and they have an IIS (6?) webserver with a secure certificate that stopped responding to https requests that came through their router.
So I set up a new router, same problem (the first router had other issues, as well)
Port 443 was forwarded in each router to 443 on the IIS box
Port 80 works, on both routers
The IIS server will deliver a secure page over the LAN, however.
It will send it to a machine (my laptop) that isn't part of the local Microsoft domain. If I edit my local hosts file so that the local IP points to the domain name it will serve a page on port 443 with no complaint, or I can run the machine name and it will complain that the certificate doesn't match the name I'm asking for, but it will serve the page.
There are no entries in the web server access log of any requests on 443, even when requested locally
Running the IIS certificate test app shows no errors
If you enable SSL on the machine, then the page delivered at port 80 says it must be accessed securely, so that part works.
I have done several iisresets, as well
The only thing of interest I found in the event logs was a Userenv warning about unknown computers, but it provided no detail. It may be related to other services this box provides over the LAN
I saw a mention of this on google, someone else had the problem, but no answer was provided.
I know my way around Unix and Apache, but this IIS stuff is a whole different world (sighs)
I have been helping a local non-profit, and they have an IIS (6?) webserver with a secure certificate that stopped responding to https requests that came through their router.
So I set up a new router, same problem (the first router had other issues, as well)
Port 443 was forwarded in each router to 443 on the IIS box
Port 80 works, on both routers
The IIS server will deliver a secure page over the LAN, however.
It will send it to a machine (my laptop) that isn't part of the local Microsoft domain. If I edit my local hosts file so that the local IP points to the domain name it will serve a page on port 443 with no complaint, or I can run the machine name and it will complain that the certificate doesn't match the name I'm asking for, but it will serve the page.
There are no entries in the web server access log of any requests on 443, even when requested locally
Running the IIS certificate test app shows no errors
If you enable SSL on the machine, then the page delivered at port 80 says it must be accessed securely, so that part works.
I have done several iisresets, as well
The only thing of interest I found in the event logs was a Userenv warning about unknown computers, but it provided no detail. It may be related to other services this box provides over the LAN
I saw a mention of this on google, someone else had the problem, but no answer was provided.
I know my way around Unix and Apache, but this IIS stuff is a whole different world (sighs)
That sounds like a firewall on the Windows Server dropping the packets based on their origin. Could be Windows Firewall or TCP/IP filtering (see KB article 816792).
posted by PhillC at 7:12 AM on April 30, 2011
posted by PhillC at 7:12 AM on April 30, 2011
Is it possible that your ISP is blocking the port in question?
posted by xedrik at 9:54 AM on April 30, 2011
posted by xedrik at 9:54 AM on April 30, 2011
you might want to divide and conquer.
Set up your laptop with the same IP and apache configured with a self-signed cert and a page to show you're received it.
Connect via another machine.
If you don't see the page, either the ISP is blocking 443 upstream or in the gateway router.
If you can, it's local to the Windows box. Windows Firewall is the most likely answer, but other things could also interfere.
Wireshark or TCPDump will help if you need to get to the low level "did anything get sent?" level.
posted by Mad_Carew at 10:05 AM on April 30, 2011
Set up your laptop with the same IP and apache configured with a self-signed cert and a page to show you're received it.
Connect via another machine.
If you don't see the page, either the ISP is blocking 443 upstream or in the gateway router.
If you can, it's local to the Windows box. Windows Firewall is the most likely answer, but other things could also interfere.
Wireshark or TCPDump will help if you need to get to the low level "did anything get sent?" level.
posted by Mad_Carew at 10:05 AM on April 30, 2011
So it *was* working and now it is not? Seems to me like the culprit would be the router more than anything else. If your router offers firewalling (and I assume that it does), turn off the Windows firewall (follow these instructions). This will take any local firewalling out of consideration and you don't need the firewall anyway if you are behind an external firewall.
What model router are you using? Some of them have some pretty crappy/crufty/hard to grok interfaces IMO. Are you sure that you are redirecting port 443 to the correct internal IP? Have you tried scanning the external IP with nmap? Does the port report as open? If your port is redirecting correctly and the server is up, you should be able to see it using nmap. You can also use nmap on the localhost (ie the Windows box) and check if your port is *really* open.
posted by humpy at 5:47 PM on April 30, 2011
What model router are you using? Some of them have some pretty crappy/crufty/hard to grok interfaces IMO. Are you sure that you are redirecting port 443 to the correct internal IP? Have you tried scanning the external IP with nmap? Does the port report as open? If your port is redirecting correctly and the server is up, you should be able to see it using nmap. You can also use nmap on the localhost (ie the Windows box) and check if your port is *really* open.
posted by humpy at 5:47 PM on April 30, 2011
You don't actually need nmap to tell whether the port is open from localhost's point of view - the native netstat -ab command window will show you that, and show you whether it is in fact IIS that's listening on that port.
posted by flabdablet at 4:50 AM on May 1, 2011
posted by flabdablet at 4:50 AM on May 1, 2011
This thread is closed to new comments.
If they are, the next place I'd be looking is the Windows Firewall configuration in the Control Panel, to make sure that WF isn't dropping port 443 packets.
And if that didn't work, I'd start swearing and cursing a lot. That generally helps Microsoft stuff perform at its best, in my experience.
posted by flabdablet at 6:16 AM on April 30, 2011