Yeah it's never listed IPv6 IPs in the list there.

Ideally you should never have swap usage on a firewall, but if you're hanging out at 10% usage, you probably could unallocate some VM memory. Don't forget, a state consumes about 1KiB of memory and each connection has 2 states. Just make sure you have enough memory to handle your maximum number of states. 1KiB per state, 2 states per connection.

apinger is the component that current versions of pfSense use to monitor gateways - whether each gateway is up or down, also working out latency and packet loss. Unfortunately, apinger is a rather troublesome program, as searches of this forum and especially Redmine will attest. There have been various comments endorsing the desirability of replacing apinger, such as Chris Buechler's comment on Redmine #4081 suggesting pfSense 2.3 will use something different. What is clear is that apinger thinks your gateway is going down, and pfSense is responding accordingly. What is unclear is whether your gateway is actually going down, or whether apinger is falsely concluding the gateway is down when it is not. If you are experiencing problems with apinger, it can help to check 'State Killing on Gateway Failure' in System -> Advanced, Miscellaneous tab. This option is arguably named incorrectly - it should really be called 'No state killing on gateway failure'. When checked, it stops pfSense from resetting all states using a gateway when that gateway is reported to have gone down.

@cmb: Was about to reply that's what your BIOS is reporting, something not right there. Might want to check for a BIOS update as that seems like some kind of bug with it. Glad you found a workaround at least. It was fine until I reinstalled everything…..but I had been tinkering with BIOS settings trying to get the watchdog timeouts to stop. This is the first BIOS for this board and I'm hoping SuperMicro comes up with a fix for my watchdog timeouts.  Sure seems to be a hardware issue (details in the hardware forum thread).

No, nothing logged prior to the crash. I suspect this is either a Snort memory leak or badly configured Snort. I don't know Snort that well so I could have done something stupid.

The ISP fixed it, but in the mean time I managed to mitigate the problem by executing the following script every few minutes via a cron job: #!/bin/sh ALLDEST="8.8.8.8 208.67.222.222" COUNT=1 while [ $COUNT -le 2 ] do for DEST in $ALLDEST do ping -c1 $DEST >/dev/null 2>/dev/null if [ $? -eq 0 ] then exit 0 fi done if [ $COUNT -le 1 ] then /usr/local/sbin/pfSctl -c 'interface reload wan' >/dev/null 2>&1 exit 1 fi COUNT=`expr $COUNT + 1` done The script is a hybrid based on this script and the command in the last post here since the ifconfig doesn't work for pppoe. Big thanks to those guys. All credits go to them.

@mike254: That's where it switches over to serial console up until the boot process is complete. It's probably stopping at an interface assignment prompt which is only visible on the serial console. Connect a null modem cable to the serial port and console into it and you should be able to assign the NICs and continue. Get in touch with us via support if you need further help with that. Thanks cmb Does this mean the hardware is not faulty? Are there any commands i need to enter on my terminal to access the Serial console?

@CyberTiVo: There are many reasons to have a quick simple way to have spare pfSense backups since I have had quite a few USB sticks loose their cookies. Yes, there are many reason to have a backup. There are zero reasons to make backups by using completely broken methods like trying to dd a live system. Absolutely horrible idea leading to inconsistent state and broken filesystem.

what is Apinger using as the destination ip (my gateway ip doesnt reliable respond to pings) maybe it prioritises other internet traffic over the pings also i wouldnt trust that graph (apinger)find a different tool whats your cable modem show http://192.168.100.1

I'd be happy of he would just answer the simple questions he's being asked, such as What is it that you're really trying to do?

@Panja: @Panja: Could the restrict access be done with FreeRadius? I'm going to setup radius for wifi authentication anyways. To answer my own question: not possible… I can restrict logging on to the network, but already connected devices stay connected. So for instance if I set the user logon times to be available from 07.00 - 21.00 hours. When the device is connected between this hours and does not disconnect, than the connection is still available after 21.00 hours. Only when the device gets disconnected and tries to reconnect, than the connection is not available. So setup a cron job to flush the states at 7:05.  It may interrupt a few legimate things, but it whacks the desired connections and then if they try to reconnect, they get hit by the scheduled block.

Hi David, many thanks for your reply…. to answer your question: we have several costumer connected to us via microwave. Our DC is for this costumer the internet breakout. I am the owner of the external ip-addresses. I am responsible for the communication, to and from the internet (in German called "Störerhaftung"). To guarantee that a specific costumer use a specific IP in this range , I need PPPoE, or I must use for each costumer his own VLAN with an overhead  of unused addresses (Broadcast, Net-IP). I will try your suggestion... Dirk

Thanks!  That makes sense. I should have realized it when it turned grey it was no longer being considered, but it also tries to calculate it then turns it grey which threw me off.

Looks like it should be working.  Put something else on the WAN side instead of whatever network you're plugging into and see if it works. Or start doing packet captures. Or reset and start over like I suggested before.

If you are putting the ap on the lan port of the pfsense box and you have dhcp running on that lan interface, say pfsense lan interface is 10.0.0.1 with dhcp server set to give out 1.0.0.3-10.0.0.X you can give the ap a static ip of 10.0.0.2 on the interface used to connect to pfsense and it will work on the ap stop dhcp dns and firewall set 10.0.0.1 as gateway and dns.

I, after a deep dive in packet analisys an sniffing i found out that  the problem was due to large packets with a strange (0.06 sec or greater) delay. Those packet disappears without any warning when hitting client interface. I finally found a workaround with a standard rule on client interface client --> NLB:80 with advanced features state type = none Bye, Chris

Hi Dose it happen no matter what setting you changed. It sounds like you are setting a new ip on the interface you are connected to or maybe adding a firewall rule that is blocking you.