@johnpoz Thanks for your ongoing support! Not saying it's something wrong generally in 23.09 but at least something specific :-) Either in combination with my NTP server or something went wrong during the upgrade. Went back to 23.05.01 and everything is OK again [image: 1700388875485-bildschirmfoto-2023-11-19-um-11.01.37.png] [image: 1700388884603-bildschirmfoto-2023-11-19-um-11.01.52.png] After being back to 23.09 same as before... The flag "u" and "s" appears randomly or changes after some time, currently it is set to "u": [image: 1700389038112-bildschirmfoto-2023-11-19-um-11.16.09.png]

I just ran into a headache/nightmare trying to downgrade. I was utilizing the AT&T bypass (WAN Connectivity with 802.1X Authentication Bridging and VLAN 0 PCP Tagging). I also had a hard time using a backup to restore from... For whatever reason if I redid the basic configuration at least back to the LAN being my previous IP address AND THEN did the restore it worked. But I then had to troubleshoot why I didn't have WAN access which was due to the MAC spoofing needing to be undone... Very inconvenient from the Plus license changes...

@Gcon FYI I sorted this out with Netgate support. cheers.

Looks like this: https://redmine.pfsense.org/issues/14431 You have a number of interfaces that could apply to but I'd guess it's pppoe0. Do you have IPv6 enabled on that? On any other dynamic interface types? Steve

@stephenw10 A clean reinstall fixed the easyrule issues. All working fine now.

@JuneKlein the serial port is listed in device manager but may not be com3. There is a reset procedure for this model: https://docs.netgate.com/pfsense/en/latest/solutions/netgate-4100/factory-reset.html

@stephenw10 Bless you! Have a lovely day.

Yup, rechecking I think I see the issue. The server timestamps changed when it was moved to new infrastructure so this is no longer true: https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/services_acb.php#L71 Setting that to UTC shows the correct times for me. Asked our admins how they want to handle it. I imagine correcting the server timezone will fix this but we shall see. Steve https://redmine.pfsense.org/issues/15005

FIXED. All i did was remove backend and frontend configuration and re-added it. Working fine. pcaps now show TLS communication with backend. Definitely a bug. Trying to reproduce so i can open a redmine but so far i cant.

@Gertjan My screen looks a little different, but I set it up this way and completed successfully. The 1dot~ address is the one I was trying to get from here. It seems it was actually a different one... https://blog.cloudflare.com/ja-jp/enable-private-dns-with-1-1-1-1-on-android-9-pie-ja-jp/ ! alt text

@stephenw10 said in Service Watchdog and Kea DHCP Server (kea-dhcp4): I understand. I'm just pointing out that, in general, you should not need to use the the service watchdog except when debugging some issue. So I was wondering if you had enabled it because Kea (or ISC dhcpd) was stopping unexpectedly. @stephenw10 No, I enabled Service Watchdog, because very occasionally (I am a beta tester for pfBlockerNG develop) a service stops and as a courtesy to users, it will bring it up again and send me mail, so I can check out the cause.

Yup also see your other identical question: https://forum.netgate.com/post/1136501 You must use block rules for local subnet and any for the destination in pass rules. Or you can use 'not local' as a destination but it's generally better to avoid that. Steve

What do you see from: ifconfig -vvm ix0 on each side? Assuming you're using ix0 that is.

@JonathanLee I have too. I had a client once tell me about a programming change request, “I want to be all powerful, but a prompt of, ‘Are you sure, knucklehead?’ would be great.”

@SteveITS Perfect. I'll try that. Thanks very much!

My mistake. I had changed out my network and now realize that the greyed out option is the current DNS server.

@stephenw10 Hi Stephen. I give you a reply on this tomorrow (when the error happened again ;-)) Regards, Christian

@the-loquitur WAN Net is not the Internet, it is WAN’s subnet, often a /24. If you are trying to block LAN1 from accessing 2, you need to add block rules, like: Reject from LAN1 net to LAN2 net Allow from LAN1 net to any

Hmm, that's about as safe as it could be then. Your description of the failure sounds like it might have somehow pulled in a pkg from 23.09 before the upgrade resulting in a mismatch at some point. I'm not sure how that could have happened but clearly if it wasn't online it couldn't have happened.