What about System => Advanced => Admin Access and move the default "443" port to another port. From what I know, the GUI binds to every interface, WAN included. This means that it's listening on WAN port 443 by default, but as you stated : no rule for incoming traffic so : not accessible. You moved the default VPN port from 1194 to 443. I wonder how that can actually work, if already nginx (the GUI web server) is already listening on that port. (or nginx = TCP only and VPN = UDP only ? In that case change your WAN VPN rule to UDP only  ;)) edit : everything has already been explained … yesterday ... https://forum.pfsense.org/index.php?topic=138110.0

I had this when I first setup pfSense…you might find you get a better response if you post in the general question. Not sure of your setup but maybe try OpenDNS as your DNS? What rules do you have setup...the default "Any" rules, maybe rstrict ports to 53, 80 and 443? Are you "VPN'ing" to outside your country? Google can detect you are using a VPN hence the Captcha... Not a great answer but maybe a place to start trouble shooting?

@SunDalf: Nice would be a client, which must not be installed on the client system and runs on all OS. Just execute from an USB stick https://en.wikipedia.org/wiki/Ssh_tunnel#Secure_Shell_tunneling

You made my day. Thank you very much.

https://github.com/pfsense/FreeBSD-ports/pull/432

I was thinking about that, too. I can't explain it why I could see the management interface before from a public IP despite this apparent interception of packets. I frequently disconnect my phone from WiFi and use it to test how my IP appears from the open internet. I'm fairly confident that I didn't forget to turn off WiFi when I noticed that the admin interface was available via WAN.  Also, other threads on this forum corroborate that the management interface binds on all Interfaces. Seems like a security problem to me, but no one other than the OPs seems to care in those other threads. Rather than fighting pfsense, the easier path is to just move the management ports (as our testy friend suggested) and keep them blocked rather than doing something risky and more complex like trying to keep the standard ports but not binding on certain interfaces. Getting back to the mystery of how some packets are intercepted before hitting my firewall and some aren't.  I wouldn't put it past a cable provider or cable modem manufacturer to be interfering with my connection, maybe even in intermittent ways.  I will know more after I set my reverse proxy back up after tearing it down thinking it was somehow interfering with critical aspects of the firewall.

Was temporary down it seems, all good now.

@robatwork: @kpa: If you happened to have a self-signed certificate that was created before the change linked below the newer browsers definitely didn't like it because they now require the FQDN of the system in the SubjectAltName field of the certificate. Which is where we came in  :) I don't think I will start any arguments about whether Chrome is an upstart baby browser or fully mature 9 year old browser which eclipses all other browsers by market share I meant newer versions of the mainstream browsers, not any of the completely new browsers or new forks of the existing ones. Chrome did what they had to with the validation requirements, hence the issue.

With a cluster, the certificates are shared between both nodes. If you import a cert for the secondary directly on the secondary it will be overwritten by the certs from the primary during the next config sync. You can do two things: 1. Use a single certificate to cover both nodes (SANs include hostnames for primary, secondary, and a hostname for the CARP VIP for other purposes, or perhaps a wildcard cert) and then select this for use as the GUI cert on both nodes. This is simple with ACME and the way we usually recommend doing it. 2. Import the primary and secondary GUI certs to the primary node, so they will be synchronized to both units. Then pick the certificate in the GUI settings after that.

Ok it seems nginx IS running and 'netstat -l -p tcp-a -n|grep 80' confirms this. I had some mark values in my routing and tried ping's -m but that route is for tcp. Ping -r for ignoring routing did not work. Sincerely, JC Magras

MY problem( just ahead of yours in list) shows nothing when 'ps ax| grep nginx' !  Et tu?

Good. Just for illustration, you really can break this with anything; e.g. here I replaced the string "NTP" with "NTP Lets Break This" in /usr/local/www/status_logs_common.inc, resulting in: [image: brokentabs.png]

That is dangerously incorrect. There is more to HTTPS than encryption when used properly.

Do a fresh install and stop messing with /etc/passwd.

A first simple override of the up/down for disabled interfaces: https://github.com/pfsense/pfsense/pull/3820 but perhaps there is more that can be done underneath to actually find out the hardware state even when at the pfSense software level the interface is disabled.