SSL errors
-
I'm running a small office network with pfsense using Squid, squidGuard, and snort. On some sites, the clients on the network get SSL handshake errors. I disabled Squid, squidGuard, and snort on pfsense but the errors still occur. I know the problem is with pfsense because if I connect through another internet connection, the SSL errors disappear. Any ideas what I'm doing wrong?
Thanks.
-
You haven't provided much detail. I'm assuming the errors are between a client on the LAN side and a website on the WAN side? Do the errors occur everytime with every browser on every client? What exactly is the error message the browser shows?
-
Yes, the errors are on a client on the LAN and website on the WAN. The error is an SSL timeout on the handshake. The specific error is: CFNetwork SSLHandshake failed (-9806) One website it happens on is Apple's. It's strange because it only occurs on the computer I use to administer pfsense (a Mac). The reason I believe it's some interaction with pfsense is that even if I do a recovery boot on the Mac and try to reinstall OS 10.9 on the computer, it fails to connect through the firewall. It even fails to connect if I do an internet boot, meaning nothing at all from the Mac's HD is loaded. it's seems to be linked to the MAC address of the computer. Is it possible that the firewall thinks I'm trying to log into it?
If I do a recovery boot on laptop on an outside network it connects fine.
Thanks.
-
Interesting. So the administrative laptop is the only computer having this issue? That should greatly simplify troubleshooting it.
I think the first question I would ask myself is whether the laptop is different from the problem-free workstations in any relevant way. For example, does it have dual internet access through wifi or 3g/4g? VPN? Is the clock way out sync? Etcetera. If nothing stands out that can be eliminated, then I would try to identify what is unique about the connection to the firewall.
Since only one workstation is affected, that really points to a problem on that workstation specifically. Maybe the firewall has special rules for that workstation's IP or MAC address? Have you tried changing it's IP/MAC address? Maybe it's related to the ethernet port or cable it uses having hardware trouble? Perhaps try it on a different port or ethernet wire. I think this is where I would focus a lot of attention.
If all that fails, the next thing to do is make sure all the packets are getting through. For me the easiest thing to do is to run tcpdump on the command line and see whether both sides are talking correctly. If you're not familiar with tcpdump, then you could start by looking for blocked packets in Status: System logs: Firewall. Enter the administrative computer's IP address in "Source IP Address", click on "Filter", in a separate window browse the an SSL site until the error appears, then click "Filter" again to refresh the log. If nothing appears blocked, move the IP address to the "Destination IP Address" field and click "Filter" to search again.
-
Great, thanks for the suggestions. I used the tcpdump to see I could find something, and I think I now have a hint. When the SSL handshake fails, I get the following errors:
11:29:11.585217 IP (tos 0x0, ttl 64, id 38269, offset 0, flags [DF], proto TCP (6), length 64, bad cksum 0 (->d887)!)
192.168.1.10.50096 > 10.0.1.1.https: Flags ~~, cksum 0xcce5 (incorrect -> 0x69ca), seq 3789669931, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 525693874 ecr 0,sackOK,eol], length 0On my network, the pfsense box is at 192.168.1.1. My laptop is at 192.168.1.10. But, I visited another site I don't administer that also uses pfsense, they had the pfsense box at 10.0.1.1. I hadn't realized it, but now that I think of it, these errors started after I visited that site. It looks like there's some sort lingering identification of the pfsense box with that other local ip. I don't get how it's so deeply rooted in my the laptop though.~~
-
So, I crossed out that lost portion of the post. Here's a clean version.
Great, thanks for the suggestions. I used the tcpdump to see I could find something, and I think I now have a hint. When the SSL handshake fails, I get the following errors:
11:29:11.585217 IP (tos 0x0, ttl 64, id 38269, offset 0, flags [DF], proto TCP (6), length 64, bad cksum 0 (->d887)!)
192.168.1.10.50096 > 10.0.1.1.https: Flags , cksum 0xcce5 (incorrect -> 0x69ca), seq 3789669931, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 525693874 ecr 0,sackOK,eol], length 0On my network, the pfsense box is at 192.168.1.1. My laptop is at 192.168.1.10. But, I visited another site I don't administer that also uses pfsense, they had the pfsense box at 10.0.1.1. I hadn't realized it, but now that I think of it, these errors started after I visited that site. It looks like there's some sort lingering identification of the pfsense box with that other local ip. I don't get how it's so deeply rooted in my the laptop though.
-
What is before that part of the sniff. I have to assume it resolved something to that IP.. What exactly are you doing to generate that traffic? BTW that is not an error, that is just some info about the packet - if your thinking chksum bad is an error that would prevent communication or your error?
So fix your issue on why the box is trying to go to to 10.0.1.1 if that is the not correct IP for where your trying to go. What IP are you trying to go to?
