@stephenw10 Pretty Please fix it upstream :)

Nice!

I don't personally. I don't run VMWare at all though. I know several of our devs do though and are not hitting it. Yet.

@jrey said in System logs:

@Qinn

assume you are asking about the restarting messages "check_reload_status" specifically?

they appear even if you don't run OpenVPN or IPsec or dyndns
system is just checking if it needs to do something. No harm

not related but if you are NOT running dyndns you can turn off the "Check IP Services" it will stop the system from checking your IP in at checkip.dyndns.org

Screen Shot 2023-12-11 at 11.02.43 AM.png

Sorry, my mistake I associated the Check IP Services with the logging, so I have read it wrong, as you clearly stated; "not related, but if you are...."

@SteveITS

Thanks so much for the help!

@LakeTravisBum I run my own ntp server as well. I just pointed my 2.7.2 vm to it and no issues

What was in the return via your packet capture?

So changed it to point to my ntp IP, reach started counting right away, and few minutes later at 377

ntp.jpg

Can you post your packet capture info - you can see here the client and the answer back from the server

sniff.jpg

@johnpoz
fee-faw-fum (I smell the blood of a SpammerMan) 😈

Go for a traceroute to find more information.

Unfortunately that happened to me too.

I switched to legacy boot mode and reinstalled and it worked.

@stephenw10

OK I think i understand what happened. At some point I had 3 gateways in a gateway group.

1 of these gateways was removed from the gateway group, and the interface was disabled, however, looking at my routing table I found 2 "default" gateways at the same time.

Destination Gateway Flags Netif Expire default XXX.XXX.XXX.XXX UGS igb4 default "supposedly.disabled.if.ip" UGS igb5 .......

I issued a /sbin/route -n get 'default' command manually, showing:

route to: 0.0.0.0 destination: 0.0.0.0 mask: 0.0.0.0 gateway: >>>>GATEWAY THAT WAS DISABLED IN THE UI IP ADDR HERE<<<< fib: 0 interface: igb5 flags: <UP,GATEWAY,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 0 0

In the UI -> I enabled and disabled the interface for the gateway in the UI.
after doing that, then in ifconfig -a output, I noticed that the interface no longer shows an IP Address and is not in "UP" status.

I subsequently issued a route delete default command which removed both default routes (the correct one, and the stagnant one for the now down interface), followed by adding a default route for the correct interface gateway.

I believe the issue is now resolved. since netstat -rn only shows 1 entry as 'default' now rather than two, and the route -n get default command now returns the correct gw ip addr.

FYI, this issue has been plaguing me for quite some time, it may be worth adding some logic to check for the presence of this issue if the issue is non-deterministic and/or non-reproducible. I unfortunately cannot provide reproduction steps that would lead to the loss of configuration sync between the UI and the OS, but I would note that the offending 3rd gateway interface was disabled in the UI, and unfortunately, it's interface was still up and had an ip addr, and the routing table had two routes set to "default". Not sure what here could be extrapolated as either a bug or an enhancement request to prevent the issue from reoccurring for others. It appears that the "disabled" state for the interface didn't quite make it down to the OS level bringing the interface down for the gateway. The presence of two routes both "default" I think might not be errant in load balancing scenarios (but definitely a bad deal if the interface is disabled in the UI, also, I think enabling/disabling the IF didn't seem to remove the duplicate default route entry corresponding to it)?

I would note that my gateway group is configured as "failover" rather than a Load Balancing configuration, i.e. interfaces in my gateway groups are usually categorized as tier1 & tier 2 & tier 3. So perhaps this config sync mixup between the ui and OS happened at some point during a failover, and the config "mixup" remained in this state indefinitely until manual intervention was required.

Anyhow, Thank You kindly for your help and for responding to my forum post!

Make sure the NAT rule for SIP is actually working. The states will show the translation.

@vahidmoghadam Fair enough.

@stephenw10 Thank you, I'll try this!

Well if you want to try this at the loader prompt:

set console=efi boot

There was the same issue
https://forum.netgate.com/topic/153940/openvpn-not-working-with-certificates-after-updating-from-earlier-pfsense-to-latest

@stephenw10 thank you!

@SteveITS said in System on 23.05.1-RELEASE not showing available updates?:

@ScottCall Try https://docs.netgate.com/pfsense/en/latest/troubleshooting/upgrades.html#upgrade-not-offered-library-errors

Thank you that did it (switching to the previous stable and back again)

-S