So a 4 port 1GbaseT NIC. I'd always look for something Intel based. An i350 based card would be top of my list but almost any Intel NIC would be fine. Check this link to find used OEM branded cards which are often cheaper and, importantly, not fake! https://forums.servethehome.com/index.php?threads/list-of-nics-and-their-equivalent-oem-parts.20974/

@Gertjan said in System Log Settings: You have a 5100, and you've MAXimized it, don't bother of protecting the SSD drive. I've chosen the 4100 MAX version for the same reason : Lots of log space, if needed, as a detailed log over a xx days span is part of the the security : logs shows what happens to the system. I also remote 'syslog' my logs, for backup purposes, to a NAS. Last week I started writing to remote syslog on NAS and see my pfSense logs still going so that is why I asked about disabling local logging. But I get it : You've lost a 'disk' (the emmc) ones, but now you've a sata drive (aka : the 5100 MAX). It won't happen again ^^ he SSD might die again, but no hassle, they always do, like the hard disks we use before. Easy to change, and after a "couple of years" you'll upgrade the entire device anyway ^^ Thanks. The SSD is 64gb so hopefully at my age it will last long enough that I won't need to upgrade. But I seem to say that about every piece of hardware I buy.

Delays like that are not just latency or shaping issues. There is no way anything could be delays that long. It's more likely connections failing and retrying multiple times. I would run a packet capture for that traffic and check it. See if the connection is showing multiple retries. Or anything else. It's probably going to be pretty obvious with that sort of error. Steve

@elvisimprsntr said in General question about Tailscale: https://forum.netgate.com/post/1187667 Thanks for the cross-link to the manual package update. I'm gonna try that next. BTW, it's not about expiring keys -- there's something funky in the officially release package that causes Tailscale to not come up after a restart. It won't come up manually (tailscale up fails) either. I'm whining here because that always seems to happen when I am away. I have to delete the machine in the Tailscale admin, purge everything in pfSense, then reinstall. Really messes things up.

Yes in Plus we added code to enable the authentication bridge to the AT&T router dircetly without using netgraph. That allows you to have a public IP on pfSense directly. You can still do that using the old netgraph method in CE. What you are able to do depends on what AT&T equipment and what connection type you have.

Or the check_upgrade (1): unknown error alert? That is already fixed for almost every mode.

@stephenw10 thanks man, it works now.

@bigsy It sounds fairly immune to that scenario then. What I notice here, with my n300 is, that after SIP registration, the only SIP traffic from the N300 are SIP OK responses to SIP OPTIONS from the server (local asterisk). This I took to be a keep-alive mechanism. When the firewall state's lost for whatever reason, some form of SIP packet is needed from N300 to recreate the state. That didn't come until the next SIP REGISTER and my unit's was set at 3600. I have pf states set to conservative, which AIUI keeps UDP states for 900s. Having said all that, N300 and two handsets have worked quite well for me. Android softphones are another matter! Thanks for the discussion.

Hmm, the current dev version should be fine. I'm running that here without issue.

@viragomann said in Port Forwarding not honered for .well-known/acme-challenge: @kiokoman said in Port Forwarding not honered for .well-known/acme-challenge: you should consider setting up a split DNS instead if you can You can not. Since you're doing port translation, you need the NAT rule on pfSense. However , I'm wondering why your server use non-default ports fot HTTP/S. With default ports you could go with local host overrides and get rid of NAT reflection. you can use haproxy in this scenario listening on wan and lan instead of opening ports/creating a nats for each pod in Kubernetes, well if you have a couple of pods it doesn't really matter but since I have 50 services running in test / 50 in staging / 50 in production on Kubernetes behind pfsense it would be unmanageable without haproxy for me

@johnpoz said in Blocking DNS over HTTPS. Seems the only way is to fire a shotgun at it: local-zone: "use-application-dns.net" always_nxdomain local-zone: "local." always_nxdomain local-data: "dns.adguard.com. 120 IN A 172.19.19.19" local-data: "dns-family.adguard.com. 120 IN A 172.19.19.19" local-data: "dns.google. 120 IN A 172.19.19.19" local-data: "cloudflare-dns.com. 120 IN A 172.19.19.19" local-data: "dns.quad9.net. 120 IN A 172.19.19.19" local-data: "dns9.quad9.net. 120 IN A 172.19.19.19" local-data: "dns10.quad9.net. 120 IN A 172.19.19.19" Oh, now clear me forget to set option "server:"

What is logged when that happens? How is UPnP configured? What pfSense version is that? Steve

Maybe this will help: https://docs.netgate.com/pfsense/en/latest/hardware/size.html

No worries, glad it helped.

@keyser Thank you for your help with this.

Thank you @viragomann and @Popolou for your help! I will do some more evaluation and consider a smart host.

Hmm, how are the clients configured for IPv6?

That's a filesystem error. Backtrace: db:0:kdb.enter.default> bt Tracing pid 17 tid 100143 td 0xfffffe00513cc1e0 kdb_enter() at kdb_enter+0x32/frame 0xfffffe005187ca60 vpanic() at vpanic+0x163/frame 0xfffffe005187cb90 panic() at panic+0x43/frame 0xfffffe005187cbf0 ffs_blkfree_cg() at ffs_blkfree_cg+0x67b/frame 0xfffffe005187cca0 ffs_blkfree() at ffs_blkfree+0xa9/frame 0xfffffe005187cd00 freework_freeblock() at freework_freeblock+0x62d/frame 0xfffffe005187cd80 handle_workitem_freeblocks() at handle_workitem_freeblocks+0x168/frame 0xfffffe005187cde0 process_worklist_item() at process_worklist_item+0x24c/frame 0xfffffe005187ce60 softdep_process_worklist() at softdep_process_worklist+0xed/frame 0xfffffe005187ceb0 softdep_flush() at softdep_flush+0x11f/frame 0xfffffe005187cef0 fork_exit() at fork_exit+0x7f/frame 0xfffffe005187cf30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe005187cf30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- The first thing to do here is run a manual filesystem check: https://docs.netgate.com/pfsense/en/latest/troubleshooting/filesystem-check.html#manual-filesystem-check

@stephenw10 okay - thanks. I've updated the default gateway to be a new gateway group that prioritizes cable over cell phone but has the cell phone in tier 2. I'll see what that does the next time the cable connection fails. Thanks for all the help!

So in the real setup the firewall would be at the client or in the 5G network?