@modesty On my modem (AT&T DSL 3rd party reseller - Arris NVG589) I can setup the bridge connection, but it's not called that in the settings. Then I can set a specific MAC address to get the internet address from the modem. This is the MAC address of my pfsense WAN port. Then in pfsense, my WAN port is set to use DHCP from the modem and it gets the internet address. Works just fine that way for me.

There is no kernel panic shown there, that's not a crash. Looks like you have a drive error on ada0 though. Or possibly on the the controller. You should swap it out if you can. Steve

@stephenw10 @bingo600 @stephenw10 The issue is fixed now, what I did is I went back to the console and reassign those interfaces to their respective static mappings and rename those three interfaces to random names and renamed them correctly and same thing with their DHCP ranges. Thanks, [image: 1633229437667-tabby_l7wb64gjhv.png]

@johnpoz YES that menu. It was like 'stuck' It would not go away. After closing and re-opening the tab 4 times -- it went to just the icon. Told you I was calling Rod Serling. <lol>

Sure but not configured in pfSense. The firewall has to allow the incoming connections from the VPN client to the VM and once that connection is open the customer can do whatever the server allows. You need to configure the server to allow uploads only. Steve

So the important part there is: db:0:kdb.enter.default> show pcpu cpuid = 3 dynamic pcpu = 0xfffffe007f12e380 curthread = 0xfffff8020ef64740: pid 67417 tid 100250 "unbound" curpcb = 0xfffff8020ef64ce0 fpcurthread = 0xfffff8020ef64740: pid 67417 "unbound" idlethread = 0xfffff80004340740: tid 100006 "idle: cpu3" curpmap = 0xfffff8020e6cc138 tssp = 0xffffffff83717758 commontssp = 0xffffffff83717758 rsp0 = 0xfffffe004d5b6cc0 kcr3 = 0xffffffffffffffff ucr3 = 0xffffffffffffffff scr3 = 0x0 gs32p = 0xffffffff8371df70 ldt = 0xffffffff8371dfb0 tss = 0xffffffff8371dfa0 tlb gen = 589816 curvnet = 0xfffff8000408ba80 db:0:kdb.enter.default> bt Tracing pid 67417 tid 100250 td 0xfffff8020ef64740 kdb_enter() at kdb_enter+0x37/frame 0xfffffe004d5b65b0 vpanic() at vpanic+0x197/frame 0xfffffe004d5b6600 panic() at panic+0x43/frame 0xfffffe004d5b6660 trap_fatal() at trap_fatal+0x391/frame 0xfffffe004d5b66c0 trap_pfault() at trap_pfault+0x4f/frame 0xfffffe004d5b6710 trap() at trap+0x286/frame 0xfffffe004d5b6820 calltrap() at calltrap+0x8/frame 0xfffffe004d5b6820 --- trap 0xc, rip = 0xffffffff80f712cc, rsp = 0xfffffe004d5b68f0, rbp = 0xfffffe004d5b6900 --- in_pcbdetach() at in_pcbdetach+0x3c/frame 0xfffffe004d5b6900 udp_detach() at udp_detach+0x93/frame 0xfffffe004d5b6930 sofree() at sofree+0x245/frame 0xfffffe004d5b6960 soclose() at soclose+0x30d/frame 0xfffffe004d5b69c0 _fdrop() at _fdrop+0x1a/frame 0xfffffe004d5b69e0 closef() at closef+0x23e/frame 0xfffffe004d5b6a70 closefp() at closefp+0xa0/frame 0xfffffe004d5b6ac0 amd64_syscall() at amd64_syscall+0x387/frame 0xfffffe004d5b6bf0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe004d5b6bf0 --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x800c8f47a, rsp = 0x7fffffffd978, rbp = 0x7fffffffd990 --- The msgbuf.txt file in your redacted archive appears to be damaged, I can't check it. That backtrace is not one I'm familiar with. It would be useful to compare that with the backtrace from other crashes. If it's close to identical it's probably a software issue. If it's a hardware problem they will be far more random. Steve

@tac57 said in Realtek Port Running Slow: I do have a 4 port Intel NIC sitting here hmmm, then pfSense didn't do this to you?

It depends entirely on what bandwidth you need over the VPN. Really I would suggest just testing it yourself as everyones traffic is different. Start small and go up. OpenVPN is single threaded so you may find the smaller instances work fine for you and larger instances don't give you much. Steve

Are you sure that worked in 2.5.1? It looks like this was lost in the conversion to iflib which was added in FreeBSD 12 and hence all 2.5.X pfSense releases. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246885 Steve

Usually it's because after completing the wizard ntp kicks in after a few minutes and the session cookie then becomes invalid and it expires the session. You should be able to just reconnect but the CSRF check will complain. Steve

@leumasstudios said in HELP!! Can not get my new pfsense install connected to my ISP and don't have internet!: and made sure to set the MAC address in pfsense to 63:e3. That seems suspicious. You should not need to set the MAC address if it's using a dedicated NIC (pass through). If you did it implies something else is using that MAC and spoofing it in pfSense will break layer 2. It sounds like you may have ended up with ESXi using that MAC. Steve

Yeah, this is almost certainly an issue with the USB NIC or it's driver. Do you see anything logged after restoring access or at the console? Try swapping the NIC assignments, use the USB NIC as WAN. Does the WAN now fail? Use a real NIC there is a best solution. Use VLANs with just the on-board NIC would also be better that USB. Steve

Yes, it is still the plan. Unfortunately it has taken longer to get the required pieces in place and tested that originally expected. It's hard to guess a time scale with any accuracy at this point. It will happen! Steve

@mikahe said in pfSense fatal error allowed memory exhausted cause: PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 6992529389211575168 bytes) in /etc/inc/config.gui.inc on line 40 Mmm, that's like 7000PB. An impossibly huge number! It can't be real. How big is your actual config file? What were you doing at that time? Steve

@nogbadthebad My only differences: For the first image. I am listening on 127.0.0.1 instead of *. image 5 - I did not have that. Freeradius users - Password Encryption set to MD5-Password for me.

To isolate devices on a Netgate router with switched ports, you can set the ports to act like separate ports. Each is its own network. Then devices connected via those ports are isolated unless you set firewall rules allowing them to talk to other networks. At 100 Mbit/s I'd fully expect the 2100 to be fine, running IDS. At 2000, I'd expect it to have problems. Not quite sure where the middle ground is but I'd guess around 300-500 Mbps. IDS (Snort/Suricata) is set up on an interface on the router. So it can be set up on one of the ports, generally LAN. re: IDS with VLANs, see this thread. So if you run Snort on LAN it should function for any of the VLANs that are set up on any of the LAN ports as well.

@steveits And.... SOLVED it. Without the GUI, it's almost impossible to see real issues. WITH the GUI, the problem quickly became visible: Long ago, I created a final FW Rule on WAN allowing me to control logging of dropped packets. New Port Forward configs create FW pass rules on WAN... and places them at the end. Which means the above block rule means none of the port forward pass rules do anything ;) Disabled my block, and all is well!