https://redmine.pfsense.org/issues/9527 might be of interest too for rfc 2307 enabled

That shouldn't happen, but without more details, such as a crash report, it's impossible to say why it did. First things first you need to upgrade to a supported release, 2.4.4-p2.

solved i run squidGuard - C all to rebuild files database for sorry and thanks

Hi, You have a 1GB capable switch somewhere ? Put it between your modem and pfSense and check link speed again, both WAN cables.

Looks to be some issue with the bxe driver/NIC. This doesn't look ideal: bxe0: ERROR: Changing VLAN_HWFILTER is not supported! This is also bad: Sleeping thread (tid 100411, pid 62759) owns a non-sleepable lock That seems to be the problem. It looks like a software issue, same crash every time. You might try a 2.5 snapshot to get the FreeBSD 12 drivers. Though I don't see anything to specifically address this in the driver history: https://github.com/freebsd/freebsd/commits/master/sys/dev/bxe Steve

@Azim Did you find any solution until now? because I am also not able to use skype while using transparent proxy... please let me know if you find any solution to got it working....

No worries.

Seems like an issue with the device itself. What firmware version do you have?

@johnpoz I can sing it in R&B, Pop, Hip-Hop, and Country. Still working on Rap but it doesn't sound quite right... Maybe we should form a pfBand...

@luckyzor said in SONOS and Google home mini in different VLAN ( PfSense + Unifi AC-PRO ): there are any solution without a physical manageable switch? Not any good ones - you could bridge interfaces as mentioned already... But you really should avoid that at all costs.. A smart switch that can do vlans is only around $40 USD.. Would be 8 port gig.. This would give you almost infinite flexibility in putting different devices or vswitches on different vlans. You for sure could find higher end switches with higher port density say off ebay or something.. But 8 port should give you what you need for sure.

Use ifconfig -v to see the additional values for all interfaces. Some will show more with additional verbose switches. [2.4.4-RELEASE][root@7100.stevew.lan]/root: ifconfig -v ix0 ix0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO> ether 00:08:a2:0e:a5:91 hwaddr 00:08:a2:0e:a5:91 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect status: no carrier plugged: SFP/SFP+/SFP28 10G Base-SR (LC) vendor: FINISAR CORP. PN: FTLX8571D3BCV-CK SN: ANL1C1V DATE: 2012-11-21 module temperature: 34.26 C Voltage: 3.31 Volts RX: 0.00 mW (-inf dBm) TX: 0.63 mW (-1.96 dBm) Steve

Ok, Thank You I will do some more testing/Log reading and see if I find any clues on this. will update if I find anything.

Correct. I didn't troubleshot much or check the routing table. Was in the middle of something and didn't want to digress. I'll probably be testing more in the next week or two.

Great! Thanks for the help Steve. Much appreciated!

@KOM hello KOM, ... Nice. that did the trick! Not sure why, but it worked. Also, I got another issue on my script. I was missing the full path for the wc command. Thanks!! Appreciate the tip! Fabricio.

Hmm, that could be gui variable quite easily I would think. You could add it as a feature request. Or submit a pull request... Steve

The backtrace is shown between > bt and > ps so: db:0:kdb.enter.default> bt Tracing pid 33436 tid 100218 td 0xfffff8019628a000 kdb_enter() at kdb_enter+0x3b/frame 0xfffffe022fe863f0 vpanic() at vpanic+0x194/frame 0xfffffe022fe86450 panic() at panic+0x43/frame 0xfffffe022fe864b0 pmap_remove_pages() at pmap_remove_pages+0x7fc/frame 0xfffffe022fe86590 exec_new_vmspace() at exec_new_vmspace+0x1b5/frame 0xfffffe022fe86600 exec_elf64_imgact() at exec_elf64_imgact+0x931/frame 0xfffffe022fe866f0 kern_execve() at kern_execve+0x77c/frame 0xfffffe022fe86a40 sys_execve() at sys_execve+0x4a/frame 0xfffffe022fe86ac0 amd64_syscall() at amd64_syscall+0xa38/frame 0xfffffe022fe86bf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe022fe86bf0 --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x800b4664a, rsp = 0x7fffffffe858, rbp = 0x7fffffffe9a0 --- db:0:kdb.enter.default> ps and db:0:kdb.enter.default> bt Tracing pid 11 tid 100003 td 0xfffff80006200000 sleepq_resume_thread() at sleepq_resume_thread+0x2b/frame 0xfffffe01e676f670 sleepq_timeout() at sleepq_timeout+0xb5/frame 0xfffffe01e676f6b0 softclock_call_cc() at softclock_call_cc+0x13a/frame 0xfffffe01e676f760 callout_process() at callout_process+0x1ae/frame 0xfffffe01e676f7e0 handleevents() at handleevents+0x1a8/frame 0xfffffe01e676f830 timercb() at timercb+0x2a1/frame 0xfffffe01e676f880 hpet_intr_single() at hpet_intr_single+0x1b9/frame 0xfffffe01e676f8b0 hpet_intr() at hpet_intr+0x8e/frame 0xfffffe01e676f8f0 intr_event_handle() at intr_event_handle+0x8b/frame 0xfffffe01e676f940 intr_execute_handlers() at intr_execute_handlers+0x49/frame 0xfffffe01e676f970 lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfffffe01e676f990 Xapic_isr1() at Xapic_isr1+0xd0/frame 0xfffffe01e676f990 --- interrupt, rip = 0xffffffff812f9426, rsp = 0xfffffe01e676fa60, rbp = 0xfffffe01e676fa60 --- acpi_cpu_c1() at acpi_cpu_c1+0x6/frame 0xfffffe01e676fa60 acpi_cpu_idle() at acpi_cpu_idle+0x2e7/frame 0xfffffe01e676fab0 cpu_idle_acpi() at cpu_idle_acpi+0x3f/frame 0xfffffe01e676fad0 cpu_idle() at cpu_idle+0x95/frame 0xfffffe01e676faf0 sched_idletd() at sched_idletd+0x544/frame 0xfffffe01e676fbb0 fork_exit() at fork_exit+0x83/frame 0xfffffe01e676fbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01e676fbf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- db:0:kdb.enter.default> ps The curthread line shows whatever the current was, usually what caused the crash. So, yes, all three of those are completely different which usually indicates a hardware issue of some sort. Steve