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.

@ktims: The necessary software is included (wpa_supplicant, I think, the driver should be there..), but I don't think there's any UI for this. You'll have to hack it in yourself. First create a wpa_supplicant.conf file for your network and test it on your network manually in the pfSense console. Once you've got that working, put it somewhere where it won't get overwritten. Then add the command to start wpa_supplicant as a shellcmd in the xml config file (search the forum) and it should come up automagically. Oh, i have wpa_supplicant, nice :) Problem is now, that it doesnt have wired driver :S I'll have figure out how to install it… any help there? :) cheers!

Still sounds like an issue local to that home network.  They could have multiple software firewalls, (eww!), or have outbound filtering enabled on their own hardware firewall.  Could also be a routing issue at the ISP etc.  Some traceroutes and packet captures should get it sorted out in short order…

Create an alias containing all your blocked IPs. Then use this alias in the firewall rule.

Right now the only thing I can think of is the length of your cable from pfsense and the switch. Sometimes a longer cable will fix the issue.