@charliem: @sporkme: That's the section under Services->NTP labelled "Access restrictions" with the odd note that says "these options control access to NTP from the WAN", which seems odd as they actually seem to have an effect on LAN clients and I can't imagine anyone adding the WAN interface to the list of IPs without firewalling that off.  For completeness, these are the parameters that if I uncheck them allow ntpdate and ntpd to work across all the LAN hosts: Any idea which one allows the older ntpdate to work?  Does the preferred method "ntpd -gq" work for you with the defaults? Not sure, I can test again at some point, but I've already annoyed people enough with my nagios alerts on ntp skew. :) @charliem: The crashing issue persists, so I'm trying your suggestion of commenting out the ntpd restarts in rc.newwanip and rc.newwanipv6.  I think all the clock skew that causes is also triggering issues with rekeying on one of my ipsec tunnels, so maybe that will get fixed as well. Interested in results you see. So far so good.  No ntpd crashes, and it might be too soon to tell, but no IPSEC VPN drops either, which I assume is just a side-effect of more accurate timekeeping.

Anybody have any ideas? Multicast http://en.wikipedia.org/wiki/Multicast_address http://www.firewall.cx/networking-topics/general-networking/107-network-multicast.html

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?