The logs for the system and the various services you are having problems with are probably the first place to look.

Make sure you are actually letting the upgrades finish. There is often quite a bit of package install work that gets done after the reboot.

Watching the console can help here.

Little more info.

As I'm using 2.3.4p1 now I see that when an openvpn client is stopped the routes (as seen in diag_routes.php) are removed as they should be.  In 2.4 betas they were not removed.

Same  thing happened to me  - I was a tad confused!

I rebooted again and it corrected itself..

It's already fixed I just need to bump the package versions for Monitoring and Traffic Totals packages. I'll edit when that is done.

edit: versions are now revved, an update should be available soon.

When I first start running a beta version, I'll update maybe once every two to three weeks… four if I'm being especially lazy. As we get closer to release, I'll update weekly. If there's an issue I've experienced that has been fixed, or something that wasn't affecting me but I want to test the fix for, I'll update sooner.

Then when the release hits, I'll run that for a few months before determining if I want to participate in the next beta. I usually join in for major release betas, not so much for minor ones.

ok thanks

The ICMP redirect is normal when you have the extra gateway defined like that doc describes. That same setup works fine on 2.4 here.

How are you pinging from one firewall to another?

I think the time traveller idea is more fun. 8)

I ended up reloading it from scratch.. and it fixed the issue.  Something about the upgrade it didnt like.

I don't think this issue is related to memory. The installation is running in a hyper-v guest with dual processors and 2000 MB of memory. According to the dashboard, only 15% is in use and the disks are almost empty.

^ exactly.. Which is why I stated you could just create a rule - and not log, and so did kpa.

If you the rules you created were below the default deny, then the rules you create would never been used..  Since traffic would be denied before it got to the rule ;)

Yep, current snapshot fixed it. No bug reported.

yep thats the same problem.

If I was to guess, probably the next 2 months. There seems to be a concentrated effort with most other things finally being stable "enough". There has been a general up-tick in closes vs open activity in their public bug tracker.

https://redmine.pfsense.org/projects/pfsense/roadmap

Serial working fine on my Shuttle DS68U full install on both 2.3.4 and 2.4. Same usb adapter.

Once we have a FreeBSD 11.1 base (very shortly after 2.4 releases) then we'll pick it up naturally.

Are you running pfSense in Hyper-V?  I had trouble with the service not starting and it was Hyper-V related.

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

FYI, some very good info here,
https://blog.spirotot.com/2016/06/28/pfsense-vlans-with-one-nic-nuc-a-tp-link-tl-sg108e/

Perhaps capture this somewhere, so it's tucked away for folks? Just to make it easy for others.

Thanks!

OK, this is really odd … if I run this command as a shellcmd,

service rateRRD start

=> it blocks the startup of other services. But, if I create a file inside /usr/local/etc/rc.d, named rateRRD.sh, and in that file …

#!/bin/sh service rateRRD start

This works perfectly! No blocking of other services or anything. So something not quite working right with shellcmd?

Thanks!