@pfSenseTest said in Cert Manager: Already updated. https://redmine.pfsense.org/issues/9825 Yep, we already saw that last week and enacted the lower lifetime. New installs will have the GUI cert set to that lifetime, or you can make a new one when pfSsh.php playback generateguicert if you're on a release or snapshot with the change. Just the GUI cert lifetime change is in 2.4.5, but for 2.5.0 there are more benefits. For example, the GUI has a visible warning when you exceed the limit for a server cert: [image: 1582562101995-selection_200.jpg] Plus in 2.5.0 where you can renew a cert in the GUI, there is an option to apply the lower limit at that time. [image: 1582562109474-selection_199.jpg]

I disabled the Dashboard auto-update check. The host that I am using to access the webGUI uses the pfSense as the DNS resolver. Upstream from that the pfSense is on a domain with a DNS role.

It's probably HSTS cached by your browser giving you trouble and not anything in pfSense itself. You shouldn't be using HTTP anyhow. Keep the GUI on HTTPS.

Or you can just find the specific state or states in the table and kill it/those. But sure a full flush works too ;)

Well then you would see the traffic via tcpdump then... You sure your using the correct interface em0? Capture all traffic - are you seeing traffic at all on that interface... If your not seeing traffic to whatever port its on.. Then your coming in a different interface, you have the wrong interface selected, or the wrong port. Why would you change ports? Because your block rule wasn't working and you think changing the port would magically start working? If you allow traffic, and state is created and then create a block rule - you have to flush the old state.

It doesn't look like the code that gathers the stats for RRD is aware of pools, only the main range. If there isn't already an entry on https://redmine.pfsense.org for that, open a new feature request there.

@Derelict I know this is old... I just wanted to thank you for the steps. Got me back up and running quick when a certificate was accidentally revoked. Thank you!

Its answered here https://forum.netgate.com/topic/149857/web-gui-auto-redirect-http-connection-to-https I cant close thread, can moderator do it, please. Thanks.

And this just answered my question here: https://forum.netgate.com/topic/150042/after-changing-pfsense-from-http-to-https-i-must-type-https-xxxxxx-xx-to-reach-web-page Im using custom port, so yeah. Thanks for clarification.

Depends on the network architecture. If it's a workstation VM on the same host as pfS VM, it (Private) would work. But not for Inet access for anything downstream on the LAN, not even the host. https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/create-a-virtual-switch-for-hyper-v-virtual-machines [image: 1580142587950-c70e1185-082b-486a-9d22-68b838f04cc0-image.png]

My hn0 interface is down, how do i bring it up?

Hello. I think this issue is https://redmine.pfsense.org/issues/8987 As workaround, you can apply the steps as indicated on https://redmine.pfsense.org/issues/8987 Go to SERVICES - DNS RESOLVER - GENERAL SETTINGS Go to section HOST OVERRIDES. Clic ADD. Type these values: host: ews domain: netgate.com ip: 127.0.0.1 Clic SAVE. Clic APPLY SETTINGS. Clic top left corner (Pfsense logo) and dashboard loads very fast (no slow for 60 seconds) I tried this workaround using a Pfsense server without Internet connection.

pfBlockerNG is a package and not part of the base system, so that's up to the package author to decide. In pfSense, generally speaking links to things on the firewall are not forced to a new window. The main exceptions are links to external resources, such as items in the Help menu.

@AndersKeiser said in Can't reach webgui, error took too long to respond: So the cause of the issue seems to be the wan and lan being on the same network A router want to (needs to !) route between different networks. If you have a network A and A on both side (like 192.168.1.0/24 on both sides) you should replace the router (pfSense) by a switch ;)

Yeah that alternate name is not the same as SAN in the cert.. That is so you don't get rebind or http_referer problems.. IP would not be valid there ever.. If you want to do rfc1918 IP in your cert, you would have to have your own local CA sign the cert. There is no public CA that would sign a cert with rfc1918 IPs in them.. I use san for my rfc1918 address in my web gui.. Where did you get that cert? From a public CA, or did you create the cert with CA you have running on pfsense?