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

Screenshot 2023-12-18 at 6.37.53 PM.png

!!!! CIPHER TEXT !!!! 96658 86791 06602 58887 06408 39604 09151 05508 05869 69555 04957 78785 72401 60078 36796 95036 03789 61329 36865 65780 02001

Screenshot 2023-12-18 at 6.39.56 PM.png

Decoded ATTACKATDAWN. BYDAWNIMEAN0500.NOT0915LIKEYOUDIDLASTTIME…A

I wrote this program to share with fellow students to try to get some interested in ciphers with code.

it's about 1,191 lines of code,

its on my GitHub if you want to check it out

https://github.com/JonathanDLee24/VictorCipher

@stephenw10 thanks to explain how that works. I was amazed about how much old items are listed in that config.xml file I never had pfblocker set to save configuration and but in the config.xml it was set to save. When I reinstalled it to remove it it still was set to not safe, I had to manually set to no and it finally removed it.

@johnpoz
Your telling me they are old. My immediate reaction was to tell them well when are we phasing these out? They are finally already in process to replace these machines finally.

Hmm, I would still run that test if you can so we can be sure what does arrive. If anything.

If you have details of what you had you to add on the Juniper that would be helpful.

There's no VM image specifically but you can use the 2.7.2 ISO image to install in a VM: https://www.pfsense.org/download/

If you have any real hardware available I would try that first but if not a VM is still a good test.

I think I see the problem here. Left some notes on your TAC ticket.

@stephenw10

Not sure what did it, but I moved WAN to the native 1GB and it was stuck at 45-50Mbps. Then I removed the UE0 and moved the WAN to bge1 1GB. Rebooted the router and then I was exceeding the 300Mbps ~338Mbps.

Not sure what it was but now I am back in business!

Thank you all really appreciate it!

@stephenw10 Didnt even realize that was possible! It will compliment the newsletter subscription perfectly!

Thank you @stephenw10 @SteveITS !!!

Hmm, as far as I know the order doesn't matter there. Where have you seen that cause a problem?