Since it's not in production yet, I just boot it when I'm tinkering with it, then shut it back down.  However, this error seems to have gone away since I fixed my fstab entries the other night (pfSense was originally booting off /dev/d1s1a because it was installed from USB stick, but after removing the stick, it moved to /dev/d0s1a because of the way my BIOS handles USB devices as hard drives).  Not sure if that was the underlying cause, or just coincidental.  Now OpenNTP goes through its thing in like 5-10 seconds. Also, at one point I had the box running with a USB NIC too, but switched over to the onboard and had left the configuration the same between the two.  I finally unplugged the USB NIC the night I did the fstab thing, until I'm ready to use it again… so I'm wondering if maybe OpenNTP was trying to route over the (not-connected) USB NIC. Anyways, it seems to be behaving for the time being :P

@cmb: get a packet capture of the ICMP that apinger generates and check the timestamps. I've never seen it be anything other than accurate. OK today we had a power outage and the both pfSense servers were restarted, and now it shows the right latency. I didn't change anything. That was weird, a windows-like solution :D

@podilarius: I am not sure why Endian would work and pfSense not. Have you left advanced setting alone and tried just standard MTUs? If you have installed any packages, remove them and restart. You want to get to where it is working and then make one change at a time so that you will know what is causing the problem. Actually I have tried no MTU settings, MTU settings on the LAN / WAN and I have installed no packages.  I am a firm believer in starting from scratch but out of the box in my scenario doesn't work.

That means the system clock went backwards for some reason. Isn't related to anything other than generating RRD data. System clock should sync via NTP periodically and that should get the data being collected properly again, though the system clock in some systems will drift significantly which may not be easy to work around (BIOS update or disabling ACPI in BIOS most commonly fix significant time drift if that's the case). Generally the quality RRD graph is the best place to look for connectivity problems in the past, but depending on when your system clock went nuts,you may not have that data.

It must not be the CF card then. It started doing this not very long after I built the system, so it's probably not write cycles anyway. I suppose it could be that some hardware was bad out of the box, but it was working fine at first, so I don't know. @cmb: if it were the CF you'd be seeing at least some errors in the logs, and usually a ton of them. Write errors, timeouts, something on adX or daX depending on what your CF device is.

Logging them to syslog is generally preferable. Even logs may not be telling at all though. First it's about general network troubleshooting abilities - what can you get to, what can't you get to, narrow down the problem as much as possible and troubleshoot from there. It could be any of a million things, many of which don't generate logs, from the description here.

I already spent a good 5 minutes searching and i couldn't find the answer, hence the thread.  Had the ISP waiting on teh phone so had to get a fast answer which i did thanks to mibovrd

The rules do not set a DSCP value, they only match a value that already exists in the packet. It would show up in a packet capture if the packets have already been tagged by whatever originated the traffic.

luke240778 - I am still a noob and dont't have your answers.  Since my last post, I restarted snort BUT with the "block offenders" checkbox unchecked.  This wreaked havoc on my system.  I am still reading docs on Snort and hope to be able to enable "block offenders" soon.  I have been running smoothly for 24hrs with Snort running. Sorry I couldn't help further. Brad

and ping is ICMP echo request, allowing only TCP will block pings.

Thank You jimp. My Bad. This makes sense now. Barry

A dissapointing result but hopefully save someone else some time.  ::) I'm sure it could be made to work but whether it would be worth the effort or not is debatable. It would probably be easier to just put an Intel gigabit card in the PCI slot with the case mods that requires. Steve

Hi, changed to a Huawei E1750 modem and pfSense configurations unchanged and now it seems to work like a charm even when the modem gets an update of the IP-adress. The pfSense modem support list says something about that the E173 sometimes does not have a E173 chip inside, maybe that's the problem in this case. Try changing to an different modem and the automatic reconnect may work. Maximilian

You may have to edit/save/apply a gateway under System > Routing.

ok changed to www.fark.com

@wallabybob: Perhaps Disabling pfSense option Allow intra-BSS communication will achieve something like AP isolation mode in DD-WRT (I know little about DD-WRT). Exactly, this is the same option. Steve