Re: stunnel... The issue i think is that pfSense system logs only send UDP and stunnel only accepts TCP This sounds right.

That's expected in CE. The loader.conf.lua file has hardware specific settings for various Netgate platforms and is only in Plus. The files used can be seen referenced in /boot/defaults/loader.conf.

Nope, that fine. You would only assign it if you need to access something untagged there.

@stephenw10 said in StarLink as source for NTP: @davehart said in StarLink as source for NTP: It seems reasonable to do that for refids with only unprintable/invisible characters. You mean it could be expected to return .. if it doesn't have a printable ID value? Exactly. I'd like to be scolding that instead of screen-scraping the peers billboard the web UI should be using a parsing-friendly version (which ntpq calls raw), but in fact there's no raw form of the billboards. It can be done with multiple raw queries to get the list of associations and query the raw peer variables for each association, though, which is what the billboard code in ntpq is doing. Given that lots of folks have resorted to scraping it, making sure there's something in the refid field seems wise.

@jimp said in Intermittent TLS Failures with LDAP Auth backend: and then give it another try. Fixed, really thanks jimp

@stephenw10 Added benefit of the LAN staying up while your edge Swiss Army knife is down. That makes two deliberate reasons...

That is the client utility the pulls in the available pkg repos from the netgate servers. No reboot is required. You don't need to manually install that but it also won't hurt to do so.

@fbrunken said in constant system restart after 25.11.1 update: I don't know if ZFS boot verification is associated to the message "Automatic boot verification is still running, please wait...", that if I am not mistaken has to do with verifying that my paid license is ok. It is the ZFS BE check. It's nothing to do with the Plus license. What it's doing is checking the new ZFS boot environment correctly boots completely. Once it completes boot it marks the new BE as the 'next-boot' and cancels the reboot timer. Thus if something in the upgrade would cause the system to fail it will fall back to the previous known working BE. It looks like that's what was happening in your system.

OK, thanks for the pointer. I forgot about that installer ... If it were more than 10 appliances I might consider setting up PXE-booting for that ;-) but that might be overkill for now. I'll see how it goes as soon as the hardware is here, thanks all.

Usually when you see the rule description missing like that it's because the ruleset has been reloaded since that packet was logged. pfSense tries to match the tracker ID to the ruleset to get the description but it can only reference the current rules. The actual packet is odd because it's unflagged TCP but it's blocked coming in to the WAN presumably which seems correct.

@Yamka said in pfSense LDAP authentication works, but no WebGUI access: Thank you! You are welcome

Ah, interesting. Thanks for testing that. Hmm.

Not seeing that here. How large is your config? What large sections do you have?

I have seen that once I just checked for update and didn’t install it after it would work again.

@workprdr said in Existing Modem and IP Questions: Different subnets are required. Modem at 192.168.1.1 and pfSense LAN at 192.168.2.1 avoids routing conflicts. Your current WAN IP (192.168.1.100) confirms double NAT; workable but suboptimal for inbound services. Request bridge mode from AIS if possible; otherwise keep DHCP on the modem and handle NAT/port forwarding solely on pfSense. I've already requested AIS to remotely change the modem/router to bridge mode. Thanks for your suggestions.

Hi, Upgrade confirmed, no issue! [image: 02-08-26-055113.png]

@stephenw10 And as suggested, I will set the WAN to a static IP and see about adding the gateway myself. Thanks for you help.

Yup that's expected when it gets updated.