@dochy
Have you looked at : these two
https://communities.vmware.com/t5/ESXi-Discussions/NTP-Why-will-my-host-NOT-sync-time-to-the-NTP-source/td-p/2826675

https://kb.vmware.com/s/article/1005092

And this:
Please note that “An ESXi/ESX host, by default, does not accept any NTP reply with a root dispersion greater than 1.5 seconds (1500 ms).” (https://kb.vmware.com/s/article/1035833). Hence, the customer would have to add the “tos maxdist” configuration as a workaround if they want to continue using the same configured NTP servers. A flash valye of 400 can also indicate that the maximum distance threshold has been exceeded and that the tos maxdist configuration needs to be applied.

@steveits thanks! I've changed it, i'll see how it goes :)

I applied all recommended patches and so far in last 2 days see no restarts!

@gertjan Hey there! Thank you for taking the time to reply!
I figured out what happened after taking another stab at it. Manually assigning the ports did the trick. I was able to setup the router after that.

@stephenw10 said in Pfsense as client and remote wireguard server:

You are running pfSense at both ends of this tunnel?

not running pfsense on both ends of the tunnel...
pfsense is running on my home network..
remote server(oracle) is not on pfsense.

@stephenw10 said in Pfsense as client and remote wireguard server:

You can set a static route the OracleCloud public IP via whichever WAN gateway you want.

will try it and update

@stephenw10 @Gertjan
Doh! User error. I always disable the default "admin" and create another admin user, hence why I was not able to ssh as root. This is probably why my NewAdmin is not in the "wheel" group but instead in the "nobody" group.

I can't add NewAdmin into wheel group due to

But now that I have "sudo" and I understand the cause for this workaround, I'm fine with it.

I would also check the Status > Monitoring graphs to see if there is some resource being obviously exhausted.

@stephenw10 said in Package list empty after CE upgrade to Plus 23.01:

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

Outstanding. That fixed the issue. Packages are now listed.
Thank you very much! Excellent support...

@lparker thanks for the update.
In the past, at different $WORK places, phys for NICs can get weird.
Sometimes, if you set one side fixed, say 100M, Full but the other side is set to autonegotiate, the speed can get figured out but the duplex can't. It's the way the hardware works, so you wind up with one side Txing at 100M,Full the other side receiving at 100M, Half. That cuts your speed right in half easily. Most modern sw that lets you "fix" a port, actually winds up simply restricting the autoneg options.

If you add a switch in between the laptop and it works, then I would check things like "fixed" or "autoneg".
Cables could affect ability to autoneg, especially at the higher speeds.

@gertjan
I think I just did the biggest brain fart ever. I feel like an idiot. I created the firewall rule but didn't create the NAT rule for the port forward. I got it figured out! THANK YOU EVERYONE!

@puneet1984 said in powerD only able to access one core:

$sysctl -a | grep -i cpu1
hwpstate_intel1: <Intel Speed Shift> on cpu1
hwpstate_intel1: <Intel Speed Shift> on cpu1
hwpstate_intel1: <Intel Speed Shift> on cpu1
hwpstate_intel1: <Intel Speed Shift> on cpu1

You must have been running it when you took that sysctl output though?

Seems the PBR problem is part of a bigger one. The Alias, which has a list of entries that should be routed via PBR and is used in the ruleset as destination is miracously empty. I guess that's something to do with another patch but either way it is empty and thus routing doesn't work.

Edit: sigh It's FQDNs. All aliases with FQDNs won't get correctly repopulated and are simply empty thus not working. I thought we already had that taken down...
That seems very much like https://redmine.pfsense.org/issues/9296 again?
But it's weirder as it seems every change currently in aliases, NAT, rules won't get applied at all and I have to go manually to filter-reload every time for it to show up. Just checked, duplicating a FQDN alias and it didn't show up in the tables. Only after manually filter-reloading it was there but empty. What's going on?

Trying to reboot again after deleting all wireguard weirdness, hoping to get at least all other functions back.

...
Edit2: OK that third? fourth? reboot seemed to have helped repopulate any alias at boot time correctly including DNS aliases. That way the PBRs are working again, the VPN GWs are again found. Good. Still NUT going nuts about any small change in packages, interfaces etc. But hey. Main things are again working normally...'ish.

Funny enough, now that I deleted the Wireguard interface assignments and static routes, after the reboot the service is now in "started" mode again and seems to have started the tunnels (S2S and RAS) without their fixed interface binding again. Will have to see if I recreate the old settings or leave it running for now.

...
Edit3: What the fruck? After the latest reboot it seems the package repository failures have righted itself (or Netgate's team has fixed it's certificate?) Either way pkg update is running again now.

@stephenw10

yes i guess you are right regarding the wait time for modem to restart.

@youcangetholdofjules

fdd542f4-7e56-4ca0-b762-842b4e4a832a-image.png

If you have a solid "900 mbit" you will see no spreading what so ever when doing this test :
https://www.waveform.com/tools/bufferbloat

Or, I'll bet you will see some random spreading and even spikes while up and downloading.

@rcoleman-netgate, dear, 2.5.2 is just a stop on the way of trying to get an updated version to 2.6 functional for my scenario as 2.4 is at the moment, as you can see when upgrading to 2.6 the problem of accessing external hosts persists and yes, most likely there is something wrong in my configuration, I just want to know, if is possible, which direction to point to try to solve this issue

30da97f7-0ff8-491a-ae2c-e6683f5e996e-image.png