I apologize, I do not have a solution to your problem but I do offer a work around. Why don't you connect the two switches together and have just one LAN. I understand that you are trying to save a port on your switch however such a model is a bad practice. I would recommend connecting the switches.

Well - I have reinstalled and all appears to be well now, or mostly well now I have extreme throughput slowness but that will be a different post.  Thanks for the response! -Aaron

Thanks, Didn't see that option.

Hi wallabybob, That's great advise. After enabling polling and rebooting, my problem has seemed to go away. I'm not entirly sure if polling did anything to help it - it may have just been the reboot! But if the problem comes back I'll be sure to refer here to quantify the interrupts generated. Just FYI, I was trying to do a samba (CIFS) transfer at the time over an openvpn connection (The openvpn server being seperate from the pfsense box) to a remote openvpn client in another country connected via a DSL connection (8Mbps down and 832kbps up as pfsense sees it). Before the reboot, pfsense GUI and shell access would be non-exsistant after about 2Mbps or transfers down from the remote server. After the reboot, I can hit 6Mbps (which is the max that this openvpn connection can reach for some unknown reason) without any problems. The speed measurements are from pfsense's traffic graph. Before the reboot, I knew that pfsense would become unresponsive at around 2Mbps as that's when the graph would stop working.. Cheers JT

ya ok, I figured that the openvpn method to be the easiest be intergrated all ready. Thanks for the insight.

I haven't installed any packages… if you mean State table size, then about 1450/10000 Firewall: NAT: 1:1    15 IPs Firewall: Rules        205 Rules, 99% TCP rules for specific ports No other services running... no SSH, no load balancing, no VPN, no DHCP. no SNMP..basically nothing... eth0: LAN eth1: WAN Static IP let me know if you need more info please

Thanks for the quick reply Bern, Yes indeed, my TCs are trying to access external_ip:80… that's exaclty what my problem is. I'll have a look at NAT reflection Thanks L2

You "could" set up a syslog server onthe pfSense itself. A quick google gives this: http://www.tutorialized.com/view/tutorial/Setup-a-Syslog-Server/36094 However this is NOT SUPPORTED and you are on your own if you have problems. Also it might introduce security breaches.

Thanks for replying! I wish more people here were as helpful as you were. Yes, packet sniffing showed that the problem existed outside the NIC as well. It turns out that the Broadcom NetXtreme Gigabit NICs built into my Dell 2650 were both causing many (up to 35%) CRC errors, but the addon NICs were not. I simply don't use the embedded NICs anymore - problem solved. I wonder if this is a known issue with these controllers… I can't find any info. Thanks again!

"It depends". Sticking Intel Server grade NICs in a P233 probably won't help you much.  Your underlying hardware makes a big difference and the complexity of your configuration matters a lot.  If you're running nothing more than a few firewall rules then you'll get away with lower spec hardware than if you're running multiple packages and some cheap Realtek NICs.  Quality hardware costs more money than cheap hardware ;)

I also added an FAQ entry for this: http://doc.pfsense.org/index.php/Why_do_I_get_%22login_on_console_as_root%22_messages_in_the_logs%3F

You're running systems that are woefully out of date and guess what? You ran into bugs that were fixed in subsequent versions of pfSense.  Here's a thought: UPGRADE!

You'll be better served to look at this log entry in the webGUI using Diagnostics -> System Log -> Firewall.  From there you can mouse over the "blocked" icon and it will tell you which of your firewall rules this block matched against.