No, not easily. Potentially, yes, you could replicate it to some external pool. But that's unsupported and unnecessary IMO.

@stephenw10 I'm on the stable branch 2.7.2 up to date. I have now applied all the recommended patches.

A missing unbound key might be expected after hard reboot yes. None of that explains why all the NICs stop passing traffic though. I'm not aware of any issue with igb that would present like that.

@Gertjan said in CustomDynDNS as CronJob.: Not sure if the same story works also fro IPv6 prefixes Yes, a saw the entry in my CronJobs too: [image: 1737383205918-bildschirmfoto_2025-01-20_15-23-31.png] Its the default config and also this explains why the update take happen at 06:00 am. By default it' just done every 6 hours. Also by default pfsense trigger an update only of WAN-Adress DynDNS if a reconnect was happen by ISP. But i do need to update the DynDNS of OPT3 and that seems not to be triggered if WAN was reconnected and got new IPv6-Address and IPv6-Prefix. As you can see here my IPv6 Configuration Type is set to Track Interface. [image: 1737383696948-bildschirmfoto_2025-01-20_15-32-33.png] So if my ISP delvers in the night a new IPv6-Adress also the Prefix of the LAN-Interfaces will change. This means all Server in LAN-Interfaces (in my case the OPT3 one) will get a new IPv6-Address as well, based on new IPv6-Prefix. I could let update each Server its own IPv6-Adress every night. But i decided to just Update the IPv6-Prefix of the Interface and create the full IPv6-Address of Servers by using AAAA-Records in Format: "Interface-ID" (ex. ::6743:12::f9aa::44a1). So i need just one Update to create valid IPv6-Adresses of several Servers. The DynDNS-Service adds the delivered IPv6-Prefix to each Interface-ID of Servers so it will become a valid full /128 IPv6-Address. And yes, you are right. The empty file dyndns_opt3custom-v6''3_v6.cache is not needed. I just did so for testing and find out how it works. Finally: it makes no sense to update full IPv6 of OPT3. It makes no sense that a LAN-Interface of pfsense will get a DynDNS-Address. So i do not do that. The annoying thing for me is that pfsense unfortunately only immediately after reconnect update DynDNS for WAN-IP-Addresses, but not that of LAN's depending on the WAN-Prefix. I think that is something need to be fixed by Netgate soon with an update of pfsense.

Promiscuous mode would allow all traffic to pass on the local interface. But that doesn't help traffic pass through the switch. I would still expect to see broadcast traffic there though.

Yup the size shown there is not a good metric. There are several open feature requests to change to the actual used disk size but doing so is non-trivial.

Still seems odd it stopped renewing. Let me see if that was intentional.

@stephenw10 Confirmed fixed! Thanks for the update.

Ok should be good now.

@jhg You could edit the /conf/config.xml directly. Search for 'spoofmac' and the first instance should probably be your WAN. https://docs.netgate.com/pfsense/en/latest/config/xml-configuration-file.html

@GPz1100 said in Empty Message-ID in SMTP Test email?: As I understand it, so long as there's at least one valid tlsa record, then it's all good? That's what I do, I publish the four (5 ?) "2.1.1" hashes that could be used by LE to sign my certificate. As long as one of them matches, the TLSA validation will work out : example : [image: 1737285210061-039e2d13-3531-42af-b85e-674d67acd371-image.png]

@alban4 I'm happy it worked :)

@michmoor happy it worked. I wasn't sure how it handles adding other interface(s) later. And gave it a go on testing pfSense CE. If you ever add another interfaces (virtual, pppoe) it will end up as the lowest, free OPT. OPT5 in your case on the backup node.

Ha

Nothing fixed yet for a release. Currently it's using 23.7: https://github.com/pfsense/pfsense/blob/master/src/etc/inc/globals.inc#L85

@stephenw10 ok thanks will schedule the update once I’ve backed up some files and got a copy of the firmware from TAC support.

You're only seeing that because you're running the custom package notification script. Most users don't see that and don't need to. The pfSense-upgrade package updates itself when it's run at upgrade. But you can update that anytime without issues. It's only used at upgrade.

@CatSpecial202 said in Allow only ssh login for admin: Is it possible to enable SSH login via public key for the admin user? Not only possible. Its imho pretty mandatory. Any every server device you use, rent, buy create, uses initially a SSH connection, and the admin (mostly root) + password is send to you. Or you created these when installing the OS. Os soon as you enter the first time, you create cert. Export the public part to yoruself, so you can use it with your SSH client, for example Putty. The 'admin' user on pfSense should have this part : [image: 1737040778239-f6007dfb-5168-45c3-94ac-6a40cb5ad49d-image.png] and then you select (again : pfSense) : [image: 1737040826956-7afdc234-f7df-4035-8ef6-381c4dc4708e-image.png] and from now on, your SSH client will be needing the exported cert to be able to connect to pfSense : [image: 1737040906414-69e4ee4d-b341-4809-a487-237a2f376f0a-image.png] and I have to type in the password == passphrase of the cert, not the admin password. Do this with pfSense, and any other device you can connect to over SSH - if possible. edit : don't even bother grating other users access to pfSense with non admin accounts. pfSense is a router, not some multi media file server. I always recommend severely creating an ssh admin pfSense so you can have access, when needed. Some will then never really use it afterwards. Other - like me - use it several times a day. As I use the same connection with for example WinSCP, so I can explore the file system, and look at things like using Windows explorer. Don't ask me why ^^ If needed, block the SSH port TCP 22 to some known LAN IPs. Lock your own devices, the ones you can use to connect to pfSense, with a DHCP MAC lease, so from now on they will always have the same IP. Throws these IPs in a Alias.*Use this Alias to create a LAN firewall rule. From now on, only these IPs can use the pfSense SSH port. Read security nerds will use a dedicates admin LAN, and connect to this LAN with their device to access pfSense SSH. Now lock your pfSense into a safe. Lock the safe. Done. Now you're close to what they use at Langley.

Hmm, that output looks as expected. There is no significant CPU load shown. Does it only appear when checking the dashboard in the GUI?