Thanks everyone!
I only have about a dozen extensions in Chrome, so I went through each one and disabled them until I found the culprit: Free Download Manager. ☹
That one used to work...
So I've disabled that extension for pfSense and everything is happy now.
I'll trundle over to FDM forum and post a bug report there.
Thanks again!

@jdillard Thank you! Awesome, that was quick. I have my box set to stable branch. I'll take a look at that in the next stable release.

@chrismacmahon Thank you for answering.
I'd already done it. But just to confirm, I installed a new Opera browser and tried. Same issue . Definitely a pfSense problem. I just don't know how to track it.
Could it be that there is some process or scheduled task that collects that data that is failing?

Yes, flushing the browser cache fixes many Web-related glitches.

Thank god i found out this thread :)
I was thinking, that something is wrong with my custom pfSense box, but i can confirm, that this issues still resides.
If I started a download in Firefox and then used the same Firefox browser to view the dashboard for the traffic graphs - the download would slow down a lot. When i view the dashboard from Chrome, no problem with speed.

using: 2.4.4-RELEASE-p1 (amd64)
built on Mon Nov 26 11:40:26 EST 2018
FreeBSD 11.2-RELEASE-p4

EDIT: with the latest Firefox 64.0 version, the issue is gone!

Try clearing your cookies etc, try using Incognito mode, try using a different browser. It's not a pfSense issue.

@justme2

In general, third-party tools are not the best idea on a firewall. pfSense includes a number of useful API-type function calls for parsing network masks and addresses and performing other types of IP address related functions. Take a look at the include files and functions in the /etc/inc directory on your firewall. See if the built-in functions will work for you first. You can also use any built-in PHP calls.

After a few hours, my pfsense is magically accessible on port 444 again. I think it did not change the port to default when I tried it the first time because it was not responding when I saved the change. So I have tried saving it with the default port 443 again and now it is working, I can access the openvpn and webgui on port 443 from my WAN interface. However I think it is not safe to expose the webgui to Internet so I revert to 444. I cannot restrict 443 to certain IP addresses as I want OpenVPN accessible from anywhere.

FWIW - submitted it and the response was a bit disheartening. Apparently a ticket has been open over 8 years ago on this issue. A work-around was suggested. The primary issue with "work arounds" is that at some point when a firewall's configuration is complex enough - it begins to look like a spaghetti mess. Some years ago was tasked with auditing and cleaning up a firewall where it was on the order of somewhere around 36k lines.

Every change to code on a product has a cost, but hopefully at some point this issue (and like issues) will be resolved so that work arounds aren't required. Not to mention the fact that adding unnecessary complexity simply aids in the probability of mistakes or inadvertent passing of unintended packets. There's an interesting line between simplicity and the ability to provide enough "configure-ability" to meet a variety of needs.

Bas DNS still has impacts these days ^^

Mea Culpa. Laptops loaded with BITDEFENDER 2019 are using encrypted web scan protection even when an exception is loaded for PFSENSE firewall which is triggering the error. Turning off encrypted web scan under online web protection allows the correct self-signed security error under the browsers which may be overridden.

Thanks for all. Off I go to Bitdefender to ask them to truly honor added exceptions. Sigh.

@kom thanks a lot for your help, I did the hard refresh and rebooted the system and the problem has gone.

I'm pretty sure this is fixed with 2.4.4_1. The error messages have gone away and when I reset the options the system paused for quite some time. I'm assuming it was generating the keys. I didn't get any message about key generation, though.

Hello Guys,

I did had the same problem before, notice the pfsense was routing the tracfic to the wrong gateway check your configurations under System-->Routing make sure the pfsense is pointing to the correct gateway let me know if that help Thanks.

@aramp1 Good work! Bravo 😃

@crbon said in SSL_ERROR_NO_CYPHER_OVERLAP when trying to connect to webgui:

When the access the same IP 192.168.1.1 from my PC (running Bitdefender AV) I get the SSL_ERROR_NO_CYPHER_OVERLAP error message instead, and there is no way to bypass it.

So that means the AV (Bitdefender in this case) is messing with the connection/certificate as a defense mechanism?

(I have ntopng installed as per @jgravert 's reference to the other thread)

Defiantly Bitdefender Scan SSL (Encrypted web scan) is active. You may need to flushdns, cache, then restart your browser after turning off Scan SSL in Bitdefender. I had to in order to get mine working again.

Alternatively if you get new CA and Certificates then install them on your PC it shouldn't matter if Scan SSL is active.

If that doesn't work you may need to completely remove Bitdefender from the PC then reinstall it.

I restored a backup and then was careful to not enable DNS Forwarder while DNS Resolver was already enabled.