Backtrace: db:1:pfs> bt Tracing pid 72793 tid 100228 td 0xfffffe00d0dae3a0 kdb_enter() at kdb_enter+0x32/frame 0xfffffe00d0bc3960 vpanic() at vpanic+0x183/frame 0xfffffe00d0bc39b0 panic() at panic+0x43/frame 0xfffffe00d0bc3a10 trap_fatal() at trap_fatal+0x409/frame 0xfffffe00d0bc3a70 trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00d0bc3ad0 calltrap() at calltrap+0x8/frame 0xfffffe00d0bc3ad0 --- trap 0xc, rip = 0xffffffff8128b0d7, rsp = 0xfffffe00d0bc3ba0, rbp = 0xfffffe00d0bc3bc0 --- free_pv_entry() at free_pv_entry+0x47/frame 0xfffffe00d0bc3bc0 pmap_remove_pte() at pmap_remove_pte+0x1c4/frame 0xfffffe00d0bc3c20 pmap_remove_ptes() at pmap_remove_ptes+0xdc/frame 0xfffffe00d0bc3c80 pmap_remove() at pmap_remove+0x53e/frame 0xfffffe00d0bc3d00 vm_map_delete() at vm_map_delete+0x1b2/frame 0xfffffe00d0bc3d70 kern_munmap() at kern_munmap+0x90/frame 0xfffffe00d0bc3e00 amd64_syscall() at amd64_syscall+0x109/frame 0xfffffe00d0bc3f30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00d0bc3f30 --- syscall (73, FreeBSD ELF64, munmap), rip = 0x230aa0651eca, rsp = 0x820adf498, rbp = 0x820adfbb0 --- Panic: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0xfffffffff5555570 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff8128b0d7 stack pointer = 0x28:0xfffffe00d0bc3ba0 frame pointer = 0x28:0xfffffe00d0bc3bc0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 72793 (php-cgi) rdi: fffffe00d13f8530 rsi: 0 rdx: feaaaaab rcx: fffffffffeaaaaab r8: fffffe00d0bc3ca8 r9: fffffe00d0bc3cc8 rax: 10000000000 rbx: 0 rbp: fffffe00d0bc3bc0 r10: 7fffffff000 r11: 0 r12: fffffe0010007300 r13: 80000000399ff467 r14: fffffe00d13f8530 r15: 40 trap number = 12 panic: page fault cpuid = 1 time = 1689655504 KDB: enter: panic Nothing very revealing there. You do have a lot of link state changes shown in the message buffer but that could have been over a long period? Steve

@nadvig23 said in Acces webui need to open 443????: Do i need to open port 443 from the consol shell? No. By default the LAN has a rule (the anti lock-out rule) that passes traffic to the webgui on the LAN IP. If you can't connect to it first make sure the client is actually in the LAN subnet. Steve

Thank you @stephenw10 You guys thought of that, fantastic

@keyser At least theres a reason for ntop's community version to be installed otherwise i question why its even in the repo I'll give it a shot. Thanks for this.

What do you see logged? What hardware are you using?

@stephenw10 yep, I would agree with this. 2.7 has been solid for me except for needing to force 2500baseT on my WAN interface.

You can simply restore the config again now it connected. Or just install the packages. The config will have been retained.

There isn't going to be a pfSense release specifically for the FreeBSD 14 release. Since we're already on 14 the change there is minimal.

Yup, testing the card in a different host is really the only way to know for sure.

@johnpoz Thanks. We were having a bandwidth throughput problem with the ISP. Long story short, the issue with throughput has been resolved and it was the provisioning the ISP had on the modem. But in the process of trying to diagnose the issue, I was going through all the settings on the gateway and noticed the broadcast address on the WAN. The interesting thing about the issue we were having is when we plugged a laptop directly into the modem, we were getting the advertised bandwidth. When we placed the Netgate 6100 between the modem and laptop, the throughput would only be 1/4 of the advertised rating. I ended up putting another laptop with iperf3 on the internal and external sides of the gateway as proof to the ISP the gateway was not limiting the bandwidth. The ISP re-provisioned the modem and that ended up resolving the issue.

@guyz said in Two Lans, possible routing issue: come from the factory with a 10.224.0.0/16 IP already and it saves me time to reconfigure ... haha - thanks.. Well that makes sense then.. [image: 1690229795962-didthematch.jpg]

@stephenw10 yeah avahi per their own website "Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite" I wouldn't have any use for DLNA discovery.. Which would be SSDP on port 1900 pretty sure..

@jimp thank you

@johnpoz Thanks. I figured we've beaten this thread for all it's worth and I should post additional FW questions in the proper section of the forum, so I had tried to post: You seem surprised. Did I mention that I'm just learning all this? :) My AP has no reference to or configuration options for a 'Management IP', so I had no idea the auth would be on anything other than the network that it was using that auth on. I know now, and I appreciate all the help I'm receiving here. But be prepared, I'll continue to have "dumb" questions, especially about the FW, until I... get it. Like this one for instance

If you allow direct remote connections to the local PCs using port forwards or some other similar mechanism that anyone that knows you address can hit, that's very insecure (e.g. RDP, VNC, etc, directly exposed to WANs). If you have them connect to a VPN first (WireGuard, IPsec, or OpenVPN) and then connect to a local system, that's not so bad. Beyond that the risk is in how much you trust the people connecting in. Ideally they'd connect to PCs/VMs in an isolated network/VLAN away from your own personal home network so they don't have any opportunity to disrupt or access your other systems.

@Gertjan [image: 1690210350437-july-netgate-in-a.png] I see what you mean by spacers, that's a lot more "horsepower" than I have, just a peer to peer setup for me. I have no IT experience, I guess that shows No server here, just a hodge podge of things I found on the cheap, except the 4100. It's such an overkill. what I ask it to do. What I really appreciate is the knowledge and experience, one can find here, and the help offered.

@stephenw10 Sorry I didn't get back to you; I must have missed the reply. I saw cores for lighttpd, pkg-static, sudo, and I think squidGuard and snort. It looked like everything went through, according to /conf/upgrade_log.latest.txt, but the last reboot didn't finish. I had to manually reset it. After that, it said it was fine. I had to put this on hold for a bit (I didn't have a USB-serial adapter handy), but eventually got it working without a reinstall: I happened across pkg-static.pkgsave, which did work. (It has the same md5sum as the pkg-static on the installation CD.) I used the command prompt at /diag_command.php, which I discovered runs commands as root, to create an ersatz su (a copy of /bin/sh that's mode 4755) I used that to run pkg-static.pkgsave bootstrap -f to reinstall pkg. The pkg command, because of a quirk of implementation, can’t update the packages database when run under my ersatz su (it uses faccessat to check the database, which checks with the real uid, not the euid). But, now that pkg was working, I could use the GUI to reinstall sudo. Using sudo, I was able to run pkg-static install -fy pkg pfSense-repo pfSense-upgrade and pkg-static upgrade -f. I later found all of my add-on packages were locked; the pkg command and the GUI would just note that they were updating the database. They wouldn’t upgrade the packages, or print a message. I ended up using pkg unlock on them. I know this is all pretty rough-and-ready work, and I’ll need to do a clean install to make sure that everything really is cleaned up. But this at least got me going until I can afford the downtime to do a clean install. The key here had been pkg-static.pkgsave; I only happened across it by accident while I was tab-completing. It may be valuable to put a note about this on the Troubleshooting Upgrades page.

@NollipfSense said in Unable to resolve acb.netgate.com notifications every 10 seconds for hours…: acb,netgate.com Check : it's acb.netgate.com A not filtered DNS, default DNS settings, using plain resolving, gives me : [23.05.1-RELEASE][root@pfSense.bhf.net]/root: host acb.netgate.com acb.netgate.com has address 208.123.73.212

So far, so good! No crashes after about 10 days since updating the BIOS/microcode. Let's hope it stays that way!