maybe checking that there is a default route out WAN for the pfSense box?  If you can ssh to the pfSense box output of "netstat -rn" should show the routing table

So apparently they don't have the code in pfsense to do this just yet. You have to create a dummy account with the same user account name that is in AD and then add that dummy account to the group. Hope they get the code soon so you don't have to have dummy accounts.

If you post the IP address from which the report was submitted and an approximate time, then someone can look at it specifically. Even if it's just the first three portions of the address, along with the time, it should be close enough. I didn't see anything from the IP address you posted from (72.193.x.x) but that doesn't mean much as it could be somewhere different from where the crash was submitted.

Thanks for the confirmation, Jim.  That's what my research was telling me as well.

@doktornotor: Not easily doable ATM. You can try the vfs.forcesync=1 mitigation. In my testing, that was no better. It's worth trying, but I wouldn't expect miracles from it. I haven't yet found any workaround that helped.

Sounds about right. While the connection numbers don't match up, HAProxy did free up swap once you closed it and swap is handled by the OS. To me that means the OS ran low on physical memory at some point in time, paged out data to swap, but then never paged the data back in. The only reason it would not page back in is because the data has not been referenced since. Anyway, still sounds like there was a lack of memory at some point, even if it only lasted for a brief moment.

Disable serial port in your BIOS.

https://www.google.com/?gws_rd=ssl#q=pfsense+active+directory => the first result

Ok, forget it. I have to select to "Edit" the CSR and it displays it in ASCII format…

Ah, attached my PPP configuration. Besides enabling the interface, I didn't do anything special. [image: 1.png] [image: 1.png_thumb] [image: 2.png] [image: 2.png_thumb]

Interesting. Pfsense #1 would be operating in transparent mode and peeling off ports to send to the other pfsense router, which would be operating in normal layer 3 mode. I have no idea if this could be made work. If your work router is getting its IP address via DHCP, you could try inserting a pfsense box in between the modem and the router modem->(WAN)pfsense(LAN)->switch->home network                                                     |                                                     |->(WAN)Router(LAN)->work network

@phil.davis: I wonder if we should ban that in the validation - not let the user put the equivalent of an internal interface name (WAN, LAN, OPT1, OPT2…) for the description of another interface. It is a total recipe for confusion if someone puts OPT5, OPT2, OPT7, OPT1, LAN... randomly as the descriptions of LAN, OPT1, OPT2, OPT3, OPT4... There is input validation there to prevent conflicting interface names on interfaces.php (so that conflict could only last until the interface is enabled). The only possibility for introducing problems there is if you can enable the same interface multiple times with the same name, which is prevented. That's the type of validation that probably goes too far, in that someone surely would complain that they can't call their <opt1>interface OPT2 (or similar). Sure it's a bad idea, but if it's not going to hurt anything, let people do what they want.</opt1>

I'm not using LDAP and I'm not on the LAN, this router is in another city…

Latency is primarily caused by one of two things, bufferbloat or distance. One way to fight the only one you have control over is to rate limit your connection. You can find better info about this in the Traffic Shaping forum.

@cmb: That's a Supermicro MAC address. Have an IPMI with a shared port? Maybe it's grabbing your IP, which creates the conflict. Something with a Supermicro NIC in it is creating the issue. The issue is introduced at your ISP's next hop router, rebooting just sends a gratuitous ARP which lets your WAN NIC take back the IP for a period of time until the other device takes it again. Super, that appears to be it! I am running a supermicro A1SRi board with a physical management port, but it was not connected to anything. I hooked it up to the switch and identified the MAC address. Appears to be a setting in the web interface with for the network port with options such as "failover", "dedicated" and "shared". It was currently configured in "failover" mode. I suppose the issue might have been fixed now that it receives a proper IP by DHCP, but I'll switch it to "dedicated" anyway. Thanks.

Like, verify the checksums and redownload it?

Bear in mind that some packages seem to make the transition better than others.

already tried vmtools via "nox" and via ESXI install CD and the results are always the same. The firewall is working ok minus this disk problem…. I think I will install an 2.2.0 version and see what values I will get on disk access. If its ok I no longer will upgrade pfsense until something or someone finds this and fixes... :( But first will try a clean 2.2.2 install, maibe I am luck with that Thank you everybody