Thanks. I reinstalled yesterday evening. Seems to be booting fine now after the fresh installation. Just have to restore the backup and I'm good. Thank you so much for the input though!

@stephenw10 OK I just deleted them all and created new ones - now 7 of them are green and 1 is red (100% packet loss) - while this is less than ideal we can live with that in the short term. What I'll do is open a support call with the provider that these tunnels go to and see what they have to say. If we identify issues with pfSense I will likely open up a new thread on this forum and link to it from here. As for the LAN drops, I think that problem is solved, we've had 2 whole working days now and its been clean. As mentioned we did rather too many changes at once to isolate which one of these might of been the solution, but thems the breaks. Of course your help has been invaluable so thank you very much for that.

@stephenw10 Unfortunately the NUT service would not restart after all this. I had to delete the package and reinstall. I think I should just wait for the officially updated package (hopefully to be released soon!)

Hmm well I know nothing about them but others may.

Thank you @stephenw10 Turned out to be a config issue on my site which I missed. (forgot to add the sync states checkbox on the secondary node)

@stephenw10 thank you. everything works fine now!

@harithruchira said in Need help to understand firewall log: What does the long log entry at 12:46:06 mean? That is dpinger, the gateway monitor, restarting. It has two instances, one on each WAN. @harithruchira said in Need help to understand firewall log: Could you explain the numbers 76642 and 76977? Those are the process IDs. OK so it looks like that first log was only the gateway log and this second log is the full system log? It's much easier to work with logs like this if you copy and paste them here rather than using screenshots. But you can see that includes entries showing ix3 relinking after you presumably rebooted the modem? Whatever was logged before that might show why it went down initially. Running both ntopng and bandwidthd at the same time can sometimes be a problem. The one thing that stands out as an issue is php coredumping at 12:48:48. However it's running again a few seconds later.

@msf24 said in ovpn client wont connect wih firewall settings on high: when updating with 3.1 router i am having connectivity issues What firewall are you using? This doesn't sound like pfSense. Steve

@stephenw10 said in Wrong timestamp in Packet Capture Output?: This should be a feature request. The ability to use local timestamps seems like a useful addition. Totally agree! Already created yesterday. It's not a bug though. Of course, just developers have not polished this many years ago.

Yes, just disable it if you're not using IPv6.

No you don't need all those rules. By default a bridge filters on the member interfaces not on the bridge itself. You've allowed for that with the group rule that gets applied to all members. Alternatively you can move the bridge filtering onto the bridge itself and then you only need rules on BR0. https://docs.netgate.com/pfsense/en/latest/bridges/firewall.html#bridging-and-firewalling However if you want to filter traffic between LAN and OPT1 you need the rules on the members. If you look at the rules you can see which ones have opened states and passed traffic. Anything that that doesn't likely doesn't need to be there. In your setup the rule(s) on the BridgeGroup override everything else so you'll likely only see states there.

@rajbps In the backen settings you can easily state the port. Just select "address + port" and enter the proper values.

Not really. I just added that URL to the config Squidguard and run the update. It takes a while to do anything. You might check the Squid/squidguard logs after trying to update. There should be an error there if it failed.

That's a normal message at boot when ntpd first starts and hasn't yet decided it's configured sources are valid.

Something there is logging a lot to make the logs rotate every few minutes like that.

I agree if it shows that uptime it's not rebooting. Odd then that it's somehow losing link. I also agree that check_reload_status should not get stuck like that. As you found we have had issues with it in the past and they are difficult to pin down because it's normally not repeatable on demand. If we can narrow it down to something like a link state change that would be very helpful.

@mer said in California and standard time: But if they set start date to 1 jan and end date to 31 dec they sidestep the "law" Nope. If a state uses any form of daylight savings time, they have to use the date schedule set forth by federal law. Originally states had the right to set their own schedules, but that was done away with in the Uniform Time Act. The only way around this is to use standard time year-around like Arizona and Hawaii.

Try starting igmpproxy in verbose mode at the CLI amd see what's shown when it fails. Compare that to what's shown in 2.6.

Use Lightsquid like it says in that guide. The sarg package was deprecated way back in 2.3.0.