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.

@SteveITS Yep. TV is a vizio flatscreen (basically a big monitor) on it's own generic UPS from walmart. pfSense, WiFi, Cablemodem all on different UPS :)

Yes, it wasn't known at release but it could certainly be there now....

You just installed the 23.09 image directly? What was different to when you initially tried to do that?