I tested my IPv6 access : I introduced a firewall rule on my HENET interface : [image: 1602092020877-32f30acb-b7d8-476a-bfd3-d69a3821dc1a-image.png] I have a DNS record that point's to my WAN IPv4, not my WAN IPv6, so I had to use my IPv6 WAN IP to connect to the GUI. I had a cert warning from my browser, of course. But the access worked well : [image: 1602091959151-63a2eab4-54c2-4efa-9ef7-04825ab0f777-image.png] "Well" means for me : knowing that my IPv6 is using a tunnel to tunnel.ne.net (Huricane IPv6 ISP) the speed was somewhat limited, about 10 Mbytes /sec. I could browse the entire pfSense GUI very well, no hick-ups .... edit : I'll leave the IPv6 access open for a while. PM me, and I can even send you an 'access' so you can test drive yourself. That is, if you promise not to change something, as this is a "live' environment ;)

Hi, The acme package uses this command (shell script) to reload the NGINX web servers after a new cert was imported. The acme package also contains the scripts that can show you how to import the certs into pfSense config.

update on this, i upped the default Firewall Maximum Table Entries from 400000 to 600000, currently sitting at 46% memory usage. Any other feedback is appreciated.

It should be possible without special settings. The CARP VIP is occupied by the master. So if you request it you should get response from the master. What exectly do you try to access? WAN from outside or LAN VIP from within you LAN?

Well, I went ahead and created https://redmine.pfsense.org/issues/10892 for the interfaces display issue

https://redmine.pfsense.org/issues/10835

Forgot to post LDAPS auth test and system logs: [image: 1599211081523-screenshot-from-2020-09-04-10-11-39.png] System logs: [image: 1599211109613-screenshot-from-2020-09-04-10-12-36.png]

@Makaveli6103 said in Cannot access WebGUI after shutdown: It is now set on https and port 80 Your browser will get mad at you. 80 (or something else) is for http 443 (or something else) is for https Mixing http and https with 80 and 443 and you have that typical 'shoot in the foot' situation. @Makaveli6103 said in Cannot access WebGUI after shutdown: How do I go about doing that in the shell? The quick and dirty : Use option 8, and type viconfig (you are using a text editor now - and this one does not behave as MS Word .... be informed). Look for the http or https port : [image: 1599198048108-3d868e97-1060-49b4-a2b5-c3ebd79c3689-image.png] If the default 443 is used, there will be no value. Add something like "4334". Write, quit, and type reboot Now, your pfSense will answer on https://192.168.1.1:443 (if https is used) Or, use the 2 option, which will re assign interfaces addresses, and will reset the GUI config back to port 80 - non https. Who is that other web server running on your pfSense ? Ask the other guy who also knows : sockstat | grep ':443'

I changed it to 5 and that seemed to fix it. I lowered it incrementally to see if it would break, and now it seems to be working even back at 1. I'll remember this trick and move it back up if it breaks again. Thanks!!!! -Chris

An important thing to remember and learn about the pfSense environment is that packages (the vast majority of them, anyway) are contributed and maintained by volunteer programmers in the true spirit of open-source. Therefore the amount of "integration" between a given package and the core pfSense firewall system is pretty much totally up to the package author/maintainer. The folks who create the pfSense firewall itself pretty much have zero to do with how individual packages operate. So the issue you see with pfBlockerNG is not something the core pfSense developers have any control over unless they were to take over the package from its creator/maintainer. The proper place to direct your input about the behavior of the pfBlockerNG package would be to the developer and maintainer of that package. He can generally be found in the pfBlockerNG sub-forum under the Packages forum here. I believe he also maintains a Reddit feed for that package.

For what it's worth : CSRF is cookie (== session) based. If a browser, or browser plugin/extension does nasty things with the cookie, CSRF kicks in.

The most common way that can happen is if you try to tell the firewall to do something which results in a page so large/long that it exhausts memory trying to display it. Gigantic logs are one way that can happen, but not usually the built-in logging since it's somewhat limited in that regard. Probably a package.