have you followed this? https://doc.pfsense.org/index.php/OpenVPN_with_RADIUS_via_Active_Directory also, openvpn questions should goto the openvpn sub-forum

There was no clear known cause I could see in the crash report, but everything centered around your bce0 NIC. Hardware issue perhaps? Or maybe some tuning changes need made. db:0:kdb.enter.default>  show pcpu cpuid        = 9 dynamic pcpu = 0xfffffe010daed800 curthread    = 0xfffff800037f0000: pid 12 "irq256: bce0" curpcb      = 0xfffffe00003a9cc0 fpcurthread  = none idlethread  = 0xfffff800035f5000: tid 100012 "idle: cpu9" curpmap      = 0xffffffff82181fd8 tssp        = 0xffffffff8219d338 commontssp  = 0xffffffff8219d338 rsp0        = 0xfffffe00003a9cc0 gs32p        = 0xffffffff8219ed90 ldt          = 0xffffffff8219edd0 tss          = 0xffffffff8219edc0 db:0:kdb.enter.default>  bt Tracing pid 12 tid 100072 td 0xfffff800037f0000 bce_intr() at bce_intr+0x4e1/frame 0xfffffe00003a9b20 intr_event_execute_handlers() at intr_event_execute_handlers+0xab/frame 0xfffffe00003a9b60 ithread_loop() at ithread_loop+0x96/frame 0xfffffe00003a9bb0 fork_exit() at fork_exit+0x9a/frame 0xfffffe00003a9bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00003a9bf0 Fatal trap 12: page fault while in kernel mode cpuid = 9; apic id = 01 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff804ad801 stack pointer         = 0x28:0xfffffe00003a9a90 frame pointer         = 0x28:0xfffffe00003a9b20 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 = 12 (irq256: bce0) There were several link state transitions for bce0 along with watchdog timeouts before the crash, but the message buffer isn't timestamped so there is no way to tell if they were immediately before the crash or some time ago: bce0: /usr/pfSensesrc/src/sys/dev/bce/if_bce.c(7869): Watchdog timeout occurred, resetting! <5>bce0: link state changed to DOWN bce0: <5>bce0: link state changed to UP Gigabit link up! bce0: Gigabit link up! <5>bce0: link state changed to DOWN bce0: <5>bce0: link state changed to UP Gigabit link up! bce0: Gigabit link up! bce0: /usr/pfSensesrc/src/sys/dev/bce/if_bce.c(7869): Watchdog timeout occurred, resetting! <5>bce0: link state changed to DOWN bce0: <5>bce0: link state changed to UP Gigabit link up! bce0: Gigabit link up! bce0: /usr/pfSensesrc/src/sys/dev/bce/if_bce.c(7869): Watchdog timeout occurred, resetting! <5>bce0: link state changed to DOWN bce0: <5>bce0: link state changed to UP Gigabit link up! bce0: Gigabit link up! <5>ovpns3: link state changed to DOWN <5>ovpns3: link state changed to UP <5>ovpns3: link state changed to DOWN <5>ovpns3: link state changed to UP bce0: /usr/pfSensesrc/src/sys/dev/bce/if_bce.c(7869): Watchdog timeout occurred, resetting! <5>bce0: link state changed to DOWN bce0: <5>bce0: link state changed to UP Gigabit link up! bce0: Gigabit link up! bce0: /usr/pfSensesrc/src/sys/dev/bce/if_bce.c(7869): Watchdog timeout occurred, resetting! <5>bce0: link state changed to DOWN bce0: <5>bce0: link state changed to UP Gigabit link up! bce0: Gigabit link up! I'd be suspicious of that NIC if it were me.

@madusanka: Hi,i have little question. im Upgrade to pfsense 2.2.3 few days ago. but now WOL is notworking and i want to know which squid and squidguard version support pfsense 2.2.3 ? Thank your help. The latest version is released 2.2.4-RELEASE. Squid 3 version 0.2.8. Squid guard devel 1.5_1beta pkg v.1.5.6

One other thing, as rsyslog server can handle upto 64K in its messages, but the udp stack can only handle 2k according to the rsyslog conversations, may be there is room for additional information upto 2k with udp and upto 64k with tcp? On the syslog incremental counter point, having a system wide incremental counter which is used by/for all syslog messages and is persistent through reboots would probably be the most useful.

Now that you point that out I feel like an idiot. Yea i was using /29 instead of /21. Thanks for the help.

Remember it: https://www.pfsense.org/ip.php

There is a package called ntop that you can install in pfSense that might do what you're looking for.  I have limited experience with it, but I think I remember it being able to show and report on which IPs were coming into/out of the firewall.

Secondhand routers are cheap to buy. I usually keep at least one spare, known working, fully tested, preconfigured and updated router at each site to swap in when I get connection problems. Usually it's a different make and model which helps eliminate manufacturer specific problems. If the spare router doesn't fix the fault, I call my ISP. I tell them I have tested the connection on two different routers and have the same fault on both of them. Since the first time I did this, I no longer have to go through verbal config instructions for them to verify settings. They get straight on to the line faults team and usually the connection is back within an hour or so or they let me know if it will be longer. On more than one occasion, I found for myself that the router had developed a hardware fault and needed replacing. The spare stayed in service and a 'new' secondhand router was purchased to replace it. In some countries, ISPs often bundle a good quality router into the sale of a new business connections. Often, these routers arrive on site and are never unboxed because the customer already has a router to connect to. I buy these for my spares at a fraction of their cost new.

Look. There are no fixes going into this dead junk. Let alone cosmetic stuff like syslog facility. More clear now?

any dumb switch for <$20 would be better than bridging ports if you ask me ;)

I'd guess that the selection is made from probably the first or last of the XXXX-quality.rrd files in the /var/db/rrd directory in whatever order they are listed by default. That would mean that you'd need to rename the interfaces to change the selection. Again, that's a guess. And I AM an idiot…

Try reading some of the posts in the Traffic Shaping forum, or ask your question there.

Hello, did you find any solution for the same. Thank You.

Actually, someone else is going to be paying for them to go faster, eventually, but not the rest of the CONCACAF nations.  It's all the poor suckers in the US paying the asinine FUSF fees.  Which is pretty much everyone.