Backtrace for reference: db:0:kdb.enter.default> bt Tracing pid 12 tid 100127 td 0xfffff8000908b000 kdb_enter() at kdb_enter+0x3b/frame 0xfffffe02399d78f0 vpanic() at vpanic+0x19b/frame 0xfffffe02399d7950 panic() at panic+0x43/frame 0xfffffe02399d79b0 trap_pfault() at trap_pfault/frame 0xfffffe02399d7a00 trap_pfault() at trap_pfault+0x49/frame 0xfffffe02399d7a60 trap() at trap+0x29d/frame 0xfffffe02399d7b70 calltrap() at calltrap+0x8/frame 0xfffffe02399d7b70 --- trap 0xc, rip = 0xffffffff80f7eb95, rsp = 0xfffffe02399d7c40, rbp = 0xfffffe02399d7e40 --- pf_test() at pf_test+0x1ef5/frame 0xfffffe02399d7e40 pf_check_out() at pf_check_out+0x1d/frame 0xfffffe02399d7e60 pfil_run_hooks() at pfil_run_hooks+0x90/frame 0xfffffe02399d7ef0 ip_output() at ip_output+0xa53/frame 0xfffffe02399d8020 ip_forward() at ip_forward+0x2c3/frame 0xfffffe02399d80c0 ip_input() at ip_input+0x724/frame 0xfffffe02399d8150 netisr_dispatch_src() at netisr_dispatch_src+0xa2/frame 0xfffffe02399d81a0 ether_demux() at ether_demux+0x15b/frame 0xfffffe02399d81d0 ether_nh_input() at ether_nh_input+0x32c/frame 0xfffffe02399d8230 netisr_dispatch_src() at netisr_dispatch_src+0xa2/frame 0xfffffe02399d8280 ether_input() at ether_input+0x26/frame 0xfffffe02399d82a0 vmxnet3_rxq_eof() at vmxnet3_rxq_eof+0x752/frame 0xfffffe02399d8330 vmxnet3_legacy_intr() at vmxnet3_legacy_intr+0xe0/frame 0xfffffe02399d8360 intr_event_execute_handlers() at intr_event_execute_handlers+0xe9/frame 0xfffffe02399d83a0 ithread_loop() at ithread_loop+0xe7/frame 0xfffffe02399d83f0 fork_exit() at fork_exit+0x83/frame 0xfffffe02399d8430 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe02399d8430 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- But, yes, many many things have been fixed since 2.4.5 so test in a current version. Also check the VMWare hypervisor and VM versions you are running.

Yup, someone probably has this working. Unfortunately I don't think I have any way to test it here.

Killing states by ruleID, or lack thereof, is probably a legacy option. pfctl has been extended a lot since pfSense was released. Or it could be that the ruleID field itself is quite new. That used to be hidden so killing states by it would have been confusing at best. It looks like pfctl can kill states by ruleID now so that could be a feature request.

We contain this by creating NAT rules on an off port from a specific IP/network that point to an internal interface (such as the LAN or Mgmt VLAN). That way there is no external attack surface. Alternatively, use a VPN when possible.

Yup that's a fun* one! More than 4 vmx NICs in esxi changes the PCI device ordering. Crazy.

Ah I see, that's a special case.

@jeffsmith82 said in Login security - phishing resistant MFA: .... From what I understand you can list multiple sites against the same key at creation time though I might be wrong. I don't believe the standard allows you to do this. Each passkey\registration is tied to a relying party which would be the current site you are accessing. You need to directly access the other servers (over HTTPS) to create registrations unique to them. If for example you access https://fire01... then the passkeys are scoped only to that FQDN and won't be presented when attempting to login to https://fire02... You would need to register a key for each server, or a common front-end that they all share. If you create on the secondary it will get overwritten by when the config syncs from the primary to secondary i would assume. It should not, my pending implementation allows you to register multiple times for the same user, which in theory should allow for other sites to be used. The only potential challenge I see is that my implementation verifies the FQDN for registration based off the configuration files (system/hostname + system/domain) . So i'm not sure how your HA deployment deals with that on the config side for both servers. Something that would need to be tested.

@stephenw10 said in Compiling and running 3rd party software on pfSense: I would expect to see at least some sort of error in the boot log when the driver attaches if the module is rejected as unsupported. Apparently you're, right: No messages were logged and - against expectations - the Zaram XGS-PON ONT SPF+ module works beautifully in my X710-DA NIC. Perhaps because it's the Intel branded version, perhaps not. But at this moment, there's no problem to solve, but that you very much for your input!

@stephenw10 said in LCP: no reply to echo request(s) Help: It looks like there's no response at all so I'd check the basics. Is it actually using the correct interface? Is the modem functioning correctly for PPPoE? I restarted the isp fibre modem that didn't help but weird when I removed the cat 6 an put it back in it started working. Weird.. Going to check the cable next an see.

@keyser said in How (and why) to create a management VLAN?: @ErniePantuso There is no “special” management VLAN entity. A management VLAN is merely a normal VLAN where you have defined Firewall rules on all pfsense Interfaces to block access to that particular VLAN/Interface. @keyser Got it. Thank you! I'm using the !RFC1918 rule on all my VLANS (with pass rules above it as necessary) so I think I pretty well have that covered. PFsense has no dependence on special interface naming, so you can just rename your LAN to MGMT if that makes sense to you according to the firewall setup. Cool. Thanks very much for the expertise and help!

The only thing I would be concerned about is the fact that igc1 lost link for some reason. Since it's connected to a switch directly it should not. Some of the early i225v revision (<rev3) chips had link issues. Try running: pciconf -lv igc1 `

Since I'm the OP I thought I'd chime in here. We changed what we do and don't clone anymore. Instead we keep a default config with 90% of the work done and have it import on a brand new install. That config does not contain the SSH keys or RRD data so we don't have to worry about it getting mixed up with other devices. Generally the only things we need to change at that point is the name and the WAN config and anything specific about that install. We leave the WAN to DHCP and plugged in upstream so that the packages reinstall on boot and then change when put in to place.

It seems far more likely that exhausting the available PHP memory causes #14061 rather than the other way around. This seems like a bug in the bind package and should be reported separately. If it hasn't been already. Steve

@stephenw10 @Gertjan Issue resolved thank you for you help. The Policy Routing Configuration doc was what I needed to follow.

@johnpoz Thank you for the quick reply. You are awesome, issue resolved!!

Actually my bad, I had to re-create all of the interfaces, etc under FreeRadius Service, its working fine now

@johnpoz said in AT&T screwed me over, now can't reach services behind pfSense from outside: One that that got my panties in a twist, is when I had an outage with comcast back in the day.. I wasn't getting an IP.. Which I clearly stated, and mentioned more than a few times.. I was showing link on the modem, but couldn't get an IP.. They wanted me to ping 8.8.8.8 - I was like how is that going to work, when I don't have an IP.. ugggghhh.. Just move me up the queue please! I feel your pain brother! Same with Spectrum (can't put what I call them). Phizix

Yup, you'd see broadcast traffic from the other firewall but unless you have something configured to do it (or misconfigured!) I wouldn't expect to see unicast between them.

@stephenw10 Thanks! It's working and I suspect I did that when I was trying to setup and test different VPNs. (Ended up with Tailscale - had issues with OpenVPN, PureVPN, and multiple others - either they couldn't do something or it was a feature trade that didn't work for me.)

That's how the xmlrpc for config sync works. It implies the secondary didn't respond for some reason. Perhaps it was down at the time?