Pfsense 2.1.2 goes down by lot of traffic
I have a pfsense box 2.1.2-RELEASE (amd64)
The box works great but when there goes a lot of traffic over it the complete box goes down!
The max stats are at 4% so na problem there, mbuf usage is around 6%
I have got the EM0 LAN cards so i added in the boot.loader.conf
In the system logs there are no errors!
So the Firewall is working great on most times and days but in the weekend when more customers visit the website the WAN goes down. I can only access the firewall througt the LAN connection and have to reboot the Firewall.
I cannot find anything in the logs. Any ideas Tips of someone with the same problems?
Sounds like you're running out of states, check Status>RRD Graphs, System tab, States from drop down, getting near or at your limit (which you can see on the dashboard)?
NO not even close. Max in de Graph is 70K now it is : 2% (34168/1635000)
chpalmer last edited by
I went back quickly through your posts but could not see how you get your internet… I may have missed it...
What kind of modem are you using? Are you double NATted by chance?
Seems like you have had to do allot of "mods" to get your setup to work correctly. Can you explain your network topology just a little here?
I have a WAN connection (Static IP directly to ISP) THE WAN interface is BRIDGED with DMZ and behind DMZ is my Switch.
All works fine Firewall is doing his job, until i think there is a lot of TCP connections through the PFsense box and all GOES down except the LAN.
MY states get dropped to ZERO alle servers behind the pfsense box are down. When i reboot the pfsense all goes up again.
What is see in the Dashboard is that my WAN OUT is sometimes over 200MB can i limit the somehow?
In the Firewall rules i added in / out traffic limit on tcp connections but that does not look to help.
chpalmer last edited by
Can you actually put your modem in bridge mode so that your pfsense box gets the actual public IP address? The way you have described it here sounds like it has a private address on your WAN interface…
Are you on Comcast by chance?
Having 200 Mb out on WAN is at least part of the issue I'm sure, what is that traffic? Diag>Packet Capture if you don't know.
All outgoing is tcp traffic. especially from one server (which is a busy chat server of a client)
Yes the WAN connection is working i do not have a modem but get direct IP from my ISP . I have 1 other pfsense not as busy as this one but he works fine.
In centos 6 a had added this to the kernel : pcie_aspm=off because of reset lan adapters. IS that also a option on Freebsd so i can try that?
So that is definitely legit traffic? It seemed like from the context earlier in this thread that pushing 200 Mb out WAN would be indicative of a general network problem of some sort, but if that's actually legit traffic, then that's no problem.
There are no parameters to touch to increase scalability outside of states and mbufs (nmbclusters setting). You said you're fine on states, and you're fine on mbufs or else your system would be kernel panicing and rebooting. Don't muck with any tunables, you're not going to improve things by doing so.
This sounds a lot like a general network issue of some sort. Rebooting the firewall does a variety of things to your network that will fix network problems entirely unrelated to the firewall, which confuses people into thinking it's a firewall problem when it really isn't at all. I suspect that as the issue at this point.
Describe the issue you're seeing in greater detail, without conflicting. You said "when there goes a lot of traffic over it the complete box goes down", but then said you can get to it on LAN no problem, so the box isn't down. What actually stops working? Can the LAN get out to the Internet when this is an issue? How is the network setup in general? NAT, routed public IPs, bridged, etc.?
Hi, The WAN - and the BRIDGE are down. NO INTERNET Acces at all. cannot obtain ubdate status etc. SO all connections except for THE LAN are down on the PFSENSE. when i go to status i see that WAN and DMZ are green and connected.
I had this problem with the intel card on centos 6 64bit, it reset and went down by a lot of traffic. Then i had to add to the kernel pcie_aspm=off, can this also be a option on the Freebsd with pfsense box?
The hosts on the bridge, what IP info they using? IPs out of the same subnet as WAN? Using WAN's gateway as their gateway?
If you go to Diag>Ping and try to go out while the bridge seems to not be working, can you ping out to the Internet? If no, what does a traceroute attempt to the Internet look like?
Also packet capture on WAN. See the traffic leaving? What's its destination MAC address?
Yes, hosts are on the same subnet on the WAN interface.
He now works fine, but when the problem occurs he gives:
built on Thu Apr 10 05:42:13 EDT 2014
Cannot Obtain update status so it looks like he has got no internet connection at that time.
This is just informational: I recently set up a new pfSense installation and tested heavy load on all interfaces mainly using NETCAT and a few other tools.
The goal was to find the best NICs and offload settings to maximise throughput. The best performance I found was by using Intel PCIe NICs with all offload settings disabled (all set in the GUI). This keeps the CPU (Core i3-3220) quite busy but still some distance to 100% CPU load even with heavy VPN traffic.
Why I'm writing this here: I tested with tons of states, with/without VPN on four Intel Gigabit NICs (3x PCIe, 1x PCI) and in some cases I had more than 800 MBit/s in AND out throughput on all IFs and the 2.1.2 pfSense was nowhere near unstable. So pfSense doesn't seem to care about heavy load at least in my case.
Since you can't check for updates, it sounds like whatever is happening is impacting the firewall itself as well as hosts behind the bridge. Time to get a packet capture on WAN while it's happening to see what's happening on the wire. What's coming in if anything, what's going out if anything.
okay, at this moment still up so did not get the error and could not check the logs.
I am considering changing the NIC in case of hardware failure