HTTPS Handshake Failing?
-
I have a wireguard tunnel to a VPN provider (Proton). It has been working perfectly for a few years. Yesterday I lost all connection through the tunnel. I cannot browse the internet on any device with any browser (Firefox, Edge, Mullvad, Brave, Safari). All browsers are giving off authentication errors.
At the time this happened I had not made any changes to anything in pfsense for over a month. I'm running CE 2.7.2 and all System Patches that are available have been applied.
After poking around I can see that states are being created through the interface:
I ran a PCap to see if I could determine what the issue might be. I suspect that something is going on with regard to TLS that is keeping the browsers from displaying the pages. Analyzing the PCap is a bit beyond my pay grade so I was hoping someone could give he a hand looking it over and potentially pointing me in the direction on how to resolve this issue.
-
Nothing in that pcap looks too bad.
What error are you actually seeing in the browser?
Are you policy routing that traffic via the VPN?
-
@stephenw10 Thanks for your help!
I am policy routing through the VPN with a firewall rule. It shows states being created:
The errors are:
Firefox & Mullvad Browsers:
Brave Browser:
Edge Browser:
I have no issues accessing the internet with apps. So for example I can get all my email via my email clients (protonmail app, my crm and thunderbird) routed through the same interface. However, I can't ping anything through the tunnel. That's why I'm thinking it has something to do with the https checks that the browsers are doing.
Just as an FYI, I even changed the VPN servers to see it it was a down server, but it is not--I get the same results on each server I connect to. Aslo, if I route my phone via Proton's VPN using Proton's VPN app and try the failing servers I used in pfsense I get no browser errors.
-
Hmm, so you only see that from one client device? Can you test from another desktop/laptop?
-
@stephenw10 I think I might have been a bit unclear in my last posting. I rechecked and can confirm that the error (not able to open things in a browser) happens on any device set to policy route through the Proton VPN tunnel. I just checked again on a Google Phone, iPhone and Tablet. They all failed. I also tried routing the devices through the Proton VPN interface on 3 different networks I have and had the same result in each network. Also note that while checking in Safari I I got this error, "An SSL error has occurred and a secure connection to the server cannot be made."
What I meant in my earlier post, which might have been confusing, is that at the same time that the computer can't access anything in a browser through the Proton VPN tunnel it can transfer data from email providers via the Proton VPN tunnel. The email clients can traverse the Proton VPN tunnel, authenticate with the mail server and pull data into the email clients.
Hope that helps!
-
Hmm, could be a packet size issue. What MTU do you have set on the WG interface? Try setting it to something smaller as a test.
-
@stephenw10 I have the MTU set at 1420 with clamping at 1360. I tried reducing them in decrements of 40 through down to 1180/1140. No luck. everything remained the same.
-
Hmm, can you ping out or traceroute using the WG interface IP as source?
-
@stephenw10 I cannot ping or traceroute from diagnostics in pfsense nor from the command prompt on a Windows matching via the Proton interface.
NAT is set to Hybrid. There is a manual outbound rule for the Proton interface:
The rule was created on 2/6/23 and updated on 6/30/24. It has been working perfectly since inception. Is there some chance that the NAT_NETWORKS alias is not be correctly read by the rule? I can confirm that the networks on which I have tested are entered correctly in the alias. But is it possible the networks are not loaded/corrupted in a config file somewhere? If that was the case, wouldn't that have prevented any states from being created?
-
When you connect out from the interface address directly there is no outbound NAT required. You should be able to ping out from it.
However you are seeing some traffic from it so perhaps you're not selecting the source correctly?
The gateway monitoring would be the same, is that showing as up for WG?
