I should have also mentioned that I used https://www.portchecktool.com/ to test my ports. I ran it from a workstation at the site where the Firebox in question is. It can't connect to port 80, 8080, or 25 saying that the connection timed out. To me, that seems consistent with the ISP blocking the ports which it's currently configured to do so. For port 443 it cannot connect either, however, the reason is because the connection was refused. That seems to me like it's making it past the ISP and to the Firebox then getting dropped.
Yes. My assumption is the port check tool site attempts to connect to the specified port on my public IP (the Firebox) and says whether it can or not. I tested port 443 from the LAN where the Firebox VPN works and it said there wasn't anything blocking port 443. On the other one it said the connection was refused. The interesting part is it says the connection times out on the ports I know are blocked by my ISP which is why I can almost certainly say it's an issue with the Firebox and not the ISP.
Ok, this is interesting. The working firebox has a valid self-signed certificate while the other one does not have one at all. I'm looking at my certificate settings on both fireboxes and they appear to be the same.
It sounds like the lack of certificate is the reason why it can't form an HTTPS connection. It still points to a device issue in my opinion though. I don't see a reason why it isn't issuing a certificate when the certificate settings are more or less identical between the two devices.
I guess my point is it doesn't seem like there's an obvious setting I can tweak to get it working. It seems like the only sure way to fix it is to tear it down and build it back up again.
Is the ISP modem a bridge or is it actually a router feeding the 26 via NAT? If the latter is true, adding the 26 to the ISP modem/router DMZ will fix that problem.
"...no point in connecting to the VPN from the internal LAN anyway." Well, other than verifying that the darn thing works at all, I guess. Every SSLVPN I have set up has always worked from the LAN side.
What do you get if you telnet to it on port 443?
How about Wireshark on your laptop? Try to connect and make sure the MAC address of the device that drops the HTTPS matches your 26.
Comments
I should have also mentioned that I used https://www.portchecktool.com/ to test my ports. I ran it from a workstation at the site where the Firebox in question is. It can't connect to port 80, 8080, or 25 saying that the connection timed out. To me, that seems consistent with the ISP blocking the ports which it's currently configured to do so. For port 443 it cannot connect either, however, the reason is because the connection was refused. That seems to me like it's making it past the ISP and to the Firebox then getting dropped.
Yes. My assumption is the port check tool site attempts to connect to the specified port on my public IP (the Firebox) and says whether it can or not. I tested port 443 from the LAN where the Firebox VPN works and it said there wasn't anything blocking port 443. On the other one it said the connection was refused. The interesting part is it says the connection times out on the ports I know are blocked by my ISP which is why I can almost certainly say it's an issue with the Firebox and not the ISP.
What's the result from an external SSL test ?
https://www.sslshopper.com/ssl-checker.html
Ok, this is interesting. The working firebox has a valid self-signed certificate while the other one does not have one at all. I'm looking at my certificate settings on both fireboxes and they appear to be the same.
If this Firebox is not responding to HTTPS or refusing the connection, then I believe that it won't provide its cert.
You can do packet captures on a firewall interface using TCP Dump.
You can set advanced options to specify the IP addr to capture and/or port, etc.
FSM:
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/fsm/log_message_learn_more_wsm.html
Web UI:
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/system_status/stats_diagnostics_tasks_web.html
It sounds like the lack of certificate is the reason why it can't form an HTTPS connection. It still points to a device issue in my opinion though. I don't see a reason why it isn't issuing a certificate when the certificate settings are more or less identical between the two devices.
What was the result, Connection Refused ?
What if you run the same test but with a :8080 suffix ?
*you'll need to open the webUI policy to Any-External temporarily...
It could be falling apart during TLS negotiation but the like versions on both don't seem to support this idea.
It's the same server that server the webUI, wsm and SSLVPN. If you can manage it then you should be able to connect over port 443..
I guess my point is it doesn't seem like there's an obvious setting I can tweak to get it working. It seems like the only sure way to fix it is to tear it down and build it back up again.
You can regenerate your firewall certs.
How do I update my Firebox certificates to use SHA-256
https://techsearch.watchguard.com/KB?type=Article&SFDCID=kA10H000000g3RlSAI&lang=en_US
Is the ISP modem a bridge or is it actually a router feeding the 26 via NAT? If the latter is true, adding the 26 to the ISP modem/router DMZ will fix that problem.
"...no point in connecting to the VPN from the internal LAN anyway." Well, other than verifying that the darn thing works at all, I guess. Every SSLVPN I have set up has always worked from the LAN side.
What do you get if you telnet to it on port 443?
How about Wireshark on your laptop? Try to connect and make sure the MAC address of the device that drops the HTTPS matches your 26.
Gregg Hill
This TCP Dump advanced parameters worked for my test from www.portchecktool.com
-i eth0 src 8.23.224.110
It shows at least 2 packets from 8.23.224.110 (www.portchecktool.com) on external (eth0).
If you see this then the firewall is receiving these TCP port 443 packets.
The response shown in www.portchecktool.com is: Connection timed out.
Bruce, I used www.portchecktool.com and got the same response after seeing it hit FSM traffic monitor. Much easier than Wireshark!
Gregg Hill
Ignore my other responses about the ISP...I didn't see page 2 when I replied.
Gregg Hill