@derelict said in Webgui Access Only by FQDN:

Yeah , but once it is connected i want page to be redirected or reloaded as https://pfsense.example.com. i have configured this behavior in my Linux web-servers running with Apache

Doesn't matter if there is a redirect. You will still get the certificate error when you initially connect because the certificate will not match the URL (IP address in this case.)

If you don't like the certificate errors going to https://192.168.1.1/ then don't go to 192.168.1.1, go to the FQDN instead.

Here, do this little experiment:

https://172.217.5.196/

Click through and see where you end up.

Thanks Derelict.
I have now added IP address in certificate and able to access Thanks for your Help.

Those kinds of changes are best submitted as a pull request on github.

Hi,

Use another browser and you'll see what happens  ;)
Or flush your current browser cache.

@dedeboy:

… but now don't enter

What was the message ?

Can anyone verify it this has been fixed in 2.4.3_1

RHLinux

I'm wondering if it can be disabled also.

The pfSense community has been using Zanata to translate text strings and Azerbaijani is already set up as one of the translations. This would be by far the best way to translate and you might even win something.

https://www.netgate.com/blog/pfsense-software-translations-with-zanata.html

If you really want to translate in a private environment, however, you can use the .po file here: /usr/local/share/locale/en_US/LC_MESSAGES/pfSense.po

@jimp:

This works fine in the ACME package:

Did you do something different?

Also, you can use the sudo package to grant other users rights to do things. It wouldn't be necessary for ACME, but for your own user it could help you out.

I think I found the problem. Silly me. I entered the command as /etc**.rc.restart_webgui instead of /etc/**rc.restart_webgui

I only realize it after I look into the screenshot.

https://doc.pfsense.org/index.php/User_Manager

Is that normal?

No.  You're missing your css and js folders.

@Katharine:

I try to do as you said but still can not solve the problem.

which part you mean you tried to do and could not solve the Problem? can you explain more about the Problem.

@jimp:

Yes, that is the correct function. If you keep the original file and then make a diff/patch from that to apply your changes, you can use the system patches package to maintain your alterations rather than redoing them after every update.

Generally speaking people using ACME/LE certs with pfSense will be using the pfSense ACME package to generate them, and we don't have an option for OSCP stapling in there, yet, either. So in terms of use with pfSense, probably not as common.

Understandable. I know this is a low priority, so I wrote teh code myself.

I've submitted a feature request https://redmine.pfsense.org/issues/8418

I've submitted a pull request https://github.com/pfsense/pfsense/pull/3927

Thanks for the link to the redmine..  Sure someone will get to sooner or later ;)

O.K. I tried setting both memory limits to 1024M and rebooting.  Unfortunately I still get the same PHP error Allowed memory size of 134217728 bytes exhausted on the pfBlockerNG Alerts page.  Since PHP is obviously configured for more "Allowed" memory than this, does anyone know where this limit is coming from?
Thanks!

Ah. I made an assumption that I was logged out if the GUI was restarted. Whoops!

Thanks for the help!

Alright! It is officially confirmed that Suricata inline mode was causing this. I recently had to switch back to Legacy mode due to another odd issue which was impacting my day-to-day. I found it impossible to manage false positives that were not showing up highlighted in the alerts log. How to you create an exception to a blocked IP which you can't even see? Maybe I was doing something wrong? In any case, I switched back to legacy mode with all the same categories and rules selected. Now the legitimate site that was blocked before is not blocked and my WAN out graph is working too. Magic! In the meantime, I'm staying away from inline mode until I grow enough courage to give it another try. I'm pretty sure it's likely a netmap issue. At one point, I couldn't even get Suricata to restart because of some netmap error. I know netmap is not a pfSense or Suricata issue in particular. I believe that's a FreeBSD thing and/or netmap being too young.