Also, more detail here: https://forum.netgate.com/topic/154467/vlans-not-working-in-20200613-0050

@bmeeks You are probably right. I did not see any realistic options as well. That is the reason, I did start this topic, just hoping anyone had a solution. However, I did write a lot of software over time, and I do have a lot of technical knowledge, but all not related to vm, github, C, FreeBSD etc. And even if I did have that, the effort of creating: vm for pfsense vm's for network, servers and pc 's as source and destination configuration testcases etc Just not realistic The only thing perhaps possible for the boot issue, is downloading the pimd source to have a look under which conditions it does generate the messages I see in the boot log. I assume that just before it generates those messages, it does perform a function call towards an OS-layer just below PIMD. That would than my No-1 verdict Louis

It would be in the <nat><outbound> section.

@bmeeks Great, this is very helpful information (and thanks for your work on the Snort package! )

All of the backtraces in that are identical: db:0:kdb.enter.default> bt Tracing pid 26689 tid 100757 td 0xfffff80251dd5620 kdb_enter() at kdb_enter+0x3b/frame 0xfffffe046257aaa0 vpanic() at vpanic+0x19b/frame 0xfffffe046257ab00 panic() at panic+0x43/frame 0xfffffe046257ab60 trap_pfault() at trap_pfault/frame 0xfffffe046257abb0 trap_pfault() at trap_pfault+0x49/frame 0xfffffe046257ac10 trap() at trap+0x29d/frame 0xfffffe046257ad20 calltrap() at calltrap+0x8/frame 0xfffffe046257ad20 --- trap 0xc, rip = 0xffffffff80e9a6fa, rsp = 0xfffffe046257adf0, rbp = 0xfffffe046257ae00 --- in_delayed_cksum() at in_delayed_cksum+0x5a/frame 0xfffffe046257ae00 pf_test() at pf_test+0x2493/frame 0xfffffe046257b010 pf_test() at pf_test+0x2088/frame 0xfffffe046257b220 pf_test() at pf_test+0x2088/frame 0xfffffe046257b430 pf_check_out() at pf_check_out+0x1d/frame 0xfffffe046257b450 pfil_run_hooks() at pfil_run_hooks+0x90/frame 0xfffffe046257b4e0 ip_output() at ip_output+0xa53/frame 0xfffffe046257b610 udp_send() at udp_send+0xa0c/frame 0xfffffe046257b6d0 sosend_dgram() at sosend_dgram+0x345/frame 0xfffffe046257b730 kern_sendit() at kern_sendit+0x1f9/frame 0xfffffe046257b7e0 sendit() at sendit+0x19e/frame 0xfffffe046257b830 sys_sendto() at sys_sendto+0x4d/frame 0xfffffe046257b880 amd64_syscall() at amd64_syscall+0xa86/frame 0xfffffe046257b9b0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe046257b9b0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x801f929ea, rsp = 0x7fffdf5f84a8, rbp = 0x7fffdf5f84f0 --- Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80e9a6fa stack pointer = 0x28:0xfffffe0462267df0 frame pointer = 0x28:0xfffffe0462267e00 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 = 11651 (unbound) trap number = 12 panic: page fault cpuid = 3 KDB: enter: panic I'm not seeing any similar backtraces for previous crashes when I search, but in_delayed_cksum at the top of that makes me suspect it may be an issue with checksum processing, but it could also be a hardware issue in general. Maybe try toggling the hardware checksum option under System > Advanced, Networking tab

The initial issue is gone now.

Crashed again. Any idea what else I might do to aid debug?

I split your posts off to a new topic since, although it was a crash, it was nowhere near the same crash. Yours is crashing in the NIC driver while processing an interrupt from a vr(4) NIC. Those Via Rhine NICs are very, very old (They're only 10/100!) and were never all that reliable. I would strongly suggest replacing that NIC with a quality Intel NIC gigabit NIC. And replace those Realtek NICs while you are at it.

There are existing examples in the code for doing this as well. Start here: https://github.com/pfsense/pfsense/blob/master/src/usr/local/bin/easyrule https://github.com/pfsense/pfsense/blob/master/src/etc/inc/easyrule.inc

Yeah if your running your esxi in your own lab with your own vms - I wouldn't use any of the mitigation anything for this family of exploits.. If there is any possible performance hit.. Which most all of these mitigations are.. Some can be a pretty stiff hit.. Do you recall when meltdown first came out.. Lots of hoopla about that.. Even though most use cases of pfsense would have zero need for concern with such an attack vector.. Lots of traffic about it here and elsewhere, etc.. negate put out this blog back Jan of 2018 https://www.netgate.com/blog/an-update-on-meltdown-and-spectre.html The important take away Most of our users should not be concerned as long as they follow our basic guidelines for limiting access to the WebGUI, shell as well as physical access to the pfSense appliance. Same goes for all of these sorts of exploits..

@kiokoman said in Here we go again.: uhm i knew it was coming neverthless it was somehow funny Exactly what she said yesterday....

You have to declare each level of the hash/array as you go. Like this: $config['vlans'] = array(); $config['vlans']['vlan'] = array(); $config['vlans']['vlan'][] = $newvlan; There is a convenience function that can help: init_config_arr(array('vlans', 'vlan')); $config['vlans']['vlan'][] = $newvlan; That function only initializes the arrays if they are unset/don't exist/are not arrays so it's safe to run unconditionally.

@Gertjan Updated OpenvpnClientExport package and checkbox works fine now. Dumb me.

On a cert, it's the refid of the CA that signed the cert. So it's copied from the CA refid.

I'm runing pfsense at a Intel(R) Core(TM) i5-5250U CPU. CPU load is low, RAM usage 23% out of 8GB. Google DNS is blocked. I use igb1. As I told, no problems without WG and full speed. WG natively runing on a Linux Mint 19.3 PC throttles the speed. Imho there is nothing wrong with Mode "Inline IPS" Edit Your requested results are in Snort.zip

@jimp said in Upgrade to 2.4.5 > 2.4.4-p3 SG-3100 ipv6 bogon list issue: It's reporting the size as it was when the page was loaded, apparently, and not what the calculated default for the system would be. That may be a bug, though it should probably report both. Well, it technically does report both in that it appropriately shows the value that was set when the page was loaded in the field where you can change the value. The bug would be that the display for the "default value" stated under the field is actually showing the currently set value.