@bdeprez said in pfsense dns lookup (netgate.com) every 30 seconds: Is there a reason for this? As said above : a TTL for a domain zone (whatever zone), I still don't know why that would be needed (exception : mega zones like Microsoft.com google.com facebook.com etc - and, afaik, netgate.com isn't that big as a company - or, for example, load scheduling over en entire server park) But as we all learn on this forum, people do things with DNS that can't be explained by reasoning. It gets even better : while posting here on the forum, I used - that is, my browser is, polling forum.netgate.com constantly. Exactly what you found. Guess what, "forum.netgate.com" also has a 60 sec TTL : so [image: 1737546395272-1b3794a9-ed4e-43eb-bd57-d3d30edbb93f-image.png] All request are received, and answered out of the (local !) unbound cache. Not sure why it asks for a IPv4. I used IPv6, and IPv4 exists as a fallback But ... I have this option checked : [image: 1737546564225-7bc6aab6-136b-402d-bb90-1a77ea3c1998-image.png] which does what it says that it does (or, probably better : what I make of it ^^ ) If an already resolved domain name, now in the resolver cache, starts to reach a zero TTL unbound will re-resolve automatically so it can answer a requesting client always right away, without going out and do the entire resolve process 'while I'm waiting (the give to take 100 ( ? ? msec this will take). So, I, the admin, was asking for it. As always, to see stupid things you need to be two : the one who creates them, and the other, who sees them. So, ones a "forum.netgate.com" resolved host name exists in my local unbound resolver cache, it will stay there, and get refreshed every TTL-10% = 54 seconds. Let's contact "netgate.com", and ask if they can lower that 60 to 1 seconds, because "why not ?!". Their domain name servers will get smacked with requests ... Btw : No, pfSEnse isn't polling netgate.com for "telemetry" reasons. pfSenses wants to resolves "netgate.com" a couple of time per day ( ? ) while checking for possible updates and some more reasons.

@stephenw10 said in Netgate 8200 connection questions: Nice! Yes I think we have seen reports of those WD 520 series working but not available new any longer AFAIK. yeah, that's the only issue; I wish I could buy new I think, I'll buy another pair, to keep as the spare. Did you move the support screw or use adapters for those? Just moved the support screws. [image: 1737444626679-d6e918e8-a1b7-40cb-9eda-c79290216ddc-image.png] Was pleased to see that mainboard has the native support of diffrent-length M.2 and Netgate was kind enough to supply the extra screws.

Is the layer3 switch routing between those VLANs? If is that could create asymmetric traffic in pfSense. But run pcaps in pfSense so you can whats actually going through both the interfaces. The earlier pcap show the server sends the Key Exchange Init packet but the client never receives it. So does that arrive at pfSense at all?

@Wylbur said in How do I figure out what part of SNORT is causing a data xfer to fail?: Meanwhile, I had not realized that this alert area was available. Apparently with the upgrade to 2.7.2? Uhh ... no. The ALERTS tab has been present in the package since the package was created. Snort has never existed on pfSense without an ALERTS tab being present. That goes back more than 12 years. There is also a Dashboard Widget that can be enabled for Snort. It shows the most recent 5 or so alerts (the exact count is configurable in the widget).

I'm returning to this thread with an update. New hardware is in place. The backup - restore - reassign interfaces process was completely flawless and painless. The new Broadcom-based ports are behaving where the previous hardware's Realtek ports were not. The problem was solved with $200 in hardware. For those reading after 2025-01-20, the price from China may be higher.

Thanks for the report. The issue may be tracked here: https://redmine.pfsense.org/issues/16005

@patient0 didn't notice that. Thanks!

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 :)