Thank you for the info. I just applied the patches using the System Patches package and the configurator seems to work fine.

So It's now all working after a reboot. I don't know exactly what change made the difference. What I did was disconnect the downstream router, reset factory defaults, set up the interfaces using autodetect, and then configured the interfaces through WebGUI. After configuring the interfaces, I copied the two default rules from LAN to OPT1. I made an error first then corrected it. At this point LAN worked fine but I had no internet on OPT1. Just so the family would have internet, I reconnected the downstream router since I ran out of time to work on it. When I came back to it later, I rebooted pfsense and everything now works. I thought I had tried that the night before, but I may not have after correcting errors in the copied firewall rules from LAN. (When I copied the rules I changed the interface from LAN to OPT1, but I forgot to also change the destination from LANnet to OPT1net.) Thanks so much for all your help! Here are the settings in case it helps someone else: (Anything related to IPv6 or DHCPv6 is likely irrelevant for me as I don't think my connection supports it) Interfaces/WAN: IPv4 - DHCP IPv6 - DHCP6 Interfaces/LAN: General Configuration: IPv4 Type - Static IPv4 IPv6 Type - Track Interface Static IPv4 Configuration: IPv4 Address - 192.168.1.1/24 IPv4 Upstream Gateway - None IPv6 Configuration: IPv6 Interface - WAN IPv6 Prefix - 0 Interfaces/OPT1 General Configuration: IPv4 Type - Static IPv4 IPv6 Type - None Static IPv4 Configuration: IPv4 Address - 192.168.3.1/24 IPv4 Upstream Gateway - None Services/DHCP Server/LAN: Enable - checked Range - 192.168.1.100 to 192.168.1.199 Services/DHCP Server/OPT1: Enable - checked Range - 192.168.3.100 to 192.168.3.199 Services/DHCPv6 Server&RA/LAN/DHCPv6 Server Enable - checked Range - ::1000 to ::2000 Prefix Delegation Size - 48 Firewall/Rules/OPT1: Edit Firewall Rule: (for first rule) Action - Pass Interface - OPT1 Address Family - IPv6 Protocol - Any Source - OPT1net Destination - any Edit Firewall Rule: (for second rule) Action - Pass Interface - OPT1 Address Family - IPv4 Protocol - Any Source - OPT1net Destination - any Settings for Verizon G1100 router: My Network/Network Connections/Broadband Connection/Settings Internet Protocol - Use the Following IP Address IP Address - 192.168.1.200 Subnet Mask - 255.255.255.0 Default Gateway - 192.168.1.1 My Network/Network Connections/Network/Settings Internet Protocol - Use the Following IP Address IP Address - 192.168.2.1 Subnet Mask - 255.255.255.0 IP Address Distribution - DHCP Server Start IP Address - 192.168.2.2 End IP Address - 192.168.2.199

Hi, Please ignore this post. it seems 3rd time lucky on installing this. Unfortunately nothing intelligent to say on how this was resolved. i must have either made a mistake in one of the setting during the first 2 installs in Virtual Box (cant imagine what though). or something is messed up on my system or installation off VirtualBox but its resolved. apologies to anyone having spend time reading :-)

@grimson said in Overly long string in System Information tab: @occamsrazor said in Overly long string in System Information tab: You can disable the Version information completely in the widget settings, or disable only the update check in the update settings. Some RTFM is in order here. Thanks, am aware you can disable the version information pane entirely, and also the update check. I don't think I or the OP want to lose that functionality. We are just talking about the length of the "Version information updated......" string. My comment "Or I'd personally be happy to have the option not to show that info at all" referred only to that string itself - not the pane as a whole or the update check functionality.

Thanks, I do have a backup from right before the attempted update. Was just curious if there was some way to do it via SSH as well.

I think there’s an option in the advanced settings regarding an HTTPS feature called HSTS (HTTP Strict Transport Security) that will tell the browser to always use HTTPS when going to that host. I believe HSTS is enabled by default when HTTPS is enabled. You may need to find where in your browser you can go to clear the HSTS setting for your pfSense hostname and/or IP address in order to access it without HTTPS. Or as suggested, you can always use a different browser.

FreeRADIUS should be passing Class as a string by default unless the OS you installed it on does something it shouldn't in its distribution. FreeRADIUS on pfSense returns Class as a string and we do not alter any of the dictionaries or config to force it to be that way. Fix your FreeRADIUS instance and it will work fine.

@grv97 if you are unable to access pfsense webgui, you have bigger issue then whatever your using as monitor not answering the zero payload monitoring ping. BTW this thread is 2 years old, cmb is no longer with us and have not seen him around for long time - he is very active at his new home unifi forums. You are more likely to get some help if you start your own thread with exact details of your problem.

Fresh install, all good now. Thanks fr your advise Best Daniel

@ivor said in Translation: Thank you! You're welcome!

Okey-dokey. Though here it reads: "Wenn nicht aktiviert, wird Port 80 automatisch auf den HTTPS Port weitergeleitet. Aktivieren, um die automatische Weiterleitung zu deaktivieren." which sounds to me, the native German speaker, the other way round. Thanks to all who answered, I think I understand the behaviour. And yet, I can't really see the point of this behaviour, to me at least it is unexpected. Not? Thanks again, Uwe

now he is logging thank you very much

I was finally able to reproduce this, turns out that for whatever reason the interfaces.php page wouldn't give me the error but if I went away to something else like DHCP settings then it failed. I opened https://redmine.pfsense.org/issues/8822 for this and just pushed a fix that corrected it for me.

What version are you running? If it was referencing PHP 7 then it must be a snapshot, or else maybe you somehow pointed 2.4.3 at the development repo and managed to mangle the packages. Best thing to do from your position is reinstall.

Hi, Correct - there is no straight forward possibility to do so, probably because way back they discovered that changing the logo didn't change anything related to firewall operations and behavior. On the other hand, for the last decade now every web browser has an "inspector" option that shows you the entire path of every image on a web site. And guess what, the pfSense GUI isn't any different. Knowing that, ans some PHP/CSS/html knowledge, and your imagination is the your only limit. Normally, you are advised to fork-of the project, and rebuild the thing own your own. Of course, totally not supported. Btw : the question the been asked a lot, and already answered as many times.

You need to have a group name that matches the group assigned in LDAP manually added to your pfSense router. So if your user is a member of "Router Admins" you need to create that same group locally on pfSense and assign it global admin privileges, since pfSense can't read those specific permissions from the LDAP schema. Are you using OpenLDAP, or Active Directory?

That is a very large amount of rules. It is entirely possible something in the switch to 2.4.4 helped -- the PHP differences are major, especially moving to PHP 7.2 may be related. You could undoubtedly drastically reduce the number of NAT rules with aliases though. I'm having trouble imagining any scenario that could possibly justify even a fraction of that amount.