@nnicanor: This option is already enabled since beta version,  all office have internet connections and direct data channel with one router that is configured in static route configuration of pfsense 2.0,  i dont have problem with this configuration with 1.2.1. See my last post. You don't have that set somewhere where you have asymmetric routing.

you have other VLANs that work fine? Where are you seeing that ARP, on the VLAN interface itself or the parent? May also want to check the parent with -e on tcpdump to ensure those have the correct VLAN tag from the switch.

I think we can consider it solved :) If any problem occurs, I will post. I will post the images soon as well. Best regards and thank you all for your patience. Kostas

That's handled on the DHCP Server page.

Should be ok now, that's from the open-vm-tools package. https://github.com/bsdperimeter/pfsense-packages/commit/bf6f1542ec79dcf5e363732f9c902b6bbd4b5535

@Technyne: @Metu69salemi: but another hand, if you're afraid of hdd wearing out, then nano is better solution. how heavily is the drive utilized with the full version vs. the Nano Version? Thanks again for you replies. In nano, the whole system is loaded into RAM and run from there with writes to the disk only happening when configuration is saved.

Well i may know something about cisco aironets, i did my bachelor thesis based on those and have worked little over year with those devices. just today i configured 9 pieces 1242ag's. So what you wanted to see

Hmm, I tested it at home with my small home router and the same issue. so I don't think it is related to pfsense, squid or loadbalancing. it's just the damn webpage ;)

Just for argument's sake, I would down the Untangle VM and see if it makes any difference, and would do all further testing with Untangle down.  Once you get the issue sorted, THEN I would revive Untangle.

I seem to be answering my own questions today, but just in case anyone else stumbles across this: I opened a command line prompt and issued a simple: ntpdate timeserver That stepped the clock forward into sync and hopefully the ntp daemon will now keep it that way. Though I've yet to figure out why it went out of sync in the first place, something to keep an eye on I guess.

There is no timestamp on those really. Those are all active connections, so the timestamp is "now". :-) There is some more information that can be had (age, expires, how many packets, what rule made it) but that would require even more parsing since it would require enabling the verbose output of the states view, and the display of that page can already take quite a bit of time with a large state table. It might be possible to add as an option in the future though.

That is from NAT reflection. It's trying to bind the reflection daemon to a high port in order to bounce connections back. That message is likely not related to what you are seeing - something else must be happening before that to trigger a reload of the LAN interface. Perhaps it's losing its link (or it believes it is). Sounds like it could be a flaky cable/NIC/switch port.

Not for an established connection. If a system properly terminates its connections, the entries go away immediately. They don't hang out there forever unless one side believes it is still open.

Even better.

@limecat: More serious, there appears to be a bug– pfSense does not want to bind with credentials. I went into iRedmail's LDAP config, and enabled anonymous bind, and all of a sudden it was able to bind no problem. How do I open a bug for this? Check pfsense's bugtracker http://redmine.pfsense.org/projects/pfsense/issues?set_filter=1

Solved! Yesterday, in desperation for an answer, I swapped the hard drive with the pfSense install on it out for another and installed Arch Linux on the machine. It took a couple of hours, but I was able to get Arch set up so that it would do exactly what I had pfSense set up for (WAN on em0, LAN on LAGG0 (em[123]), OPT1 on VLAN1 on LAGG0, and OPT2 on VLAN2 on LAGG0). Rerunning IPerf on the same pair of old and crufty workstations got exactly the same performance figures, approximately 228 Mb/s. I boggled for a minute then realised the problem was either the hardware on the pfSense box (maybe the LAGG and VLAN configuration scared up a bug) or the workstation's NICs (as limecat suggested). I plugged my fairly new laptop into a port that would use OPT1 on the pfSense box and reran IPerf to a machine on the other side of the WAN port (ie. NAT was involved). Got about 928 Mb/s. So the workstations were at fault! This is a huge relief. pfSense makes for an easier solution, than building a Linux router, to most of the problems I'm running up against (inter-subnet routing speed, web caching, traffic shaping, prioritising video-conferencing traffic).