@stephenw10 I've backup all of the pkgs :)

It's not an official mirror. You can check the file checksums here though: https://files.netgate.com/hashes/ 2.3.4p1 was never available as an image though only as an update to 2.3.4. Steve

@yoyoSE156d I mean if the NAS is not accessible externally (from the internet), and you filter traffic from the other devices to the NAS you are off to a good start. Other than that make sure to keep things up to date, and use good passwords. Unless you have some reason to think that you would be directly targeted I think that would pretty much be enough.

Those look like Speed-Shift numbers. Those are passed to the driver by the CPU/BIOS, nothing in pfSense sets them. Make sure you have the latest bios running.

pfSense doesn't use the FreeBSD rc system: https://docs.netgate.com/pfsense/en/latest/development/boot-commands.html Steve

It's probably an ACPI reported value which isn't the CPU at all. If it never changes it's probably a bogus value anyway. You should enable the appropriate CPU core temp driver in Sys > Adv > Misc.

@stephenw10 said in pfsense booting from /boot/kernel/kernel after update from 2.6.0 to 2.7.0: Ok, well check the output of show to see what it's trying to use. You might consider just installing 2.7 clean and restoring the config though. Steve Seems its the only solution

@viragomann i tried another browser but still not acessing, i use the command 16 (RESTART PHP-FRM) with SSH, and i can acess the web again, thx

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]