Pfsense 2.1.2 goes down by lot of traffic
-
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…
Correct?
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:
2.1.2-RELEASE (amd64)
built on Thu Apr 10 05:42:13 EDT 2014
FreeBSD 8.3-RELEASE-p15Cannot Obtain update status so it looks like he has got no internet connection at that time.
-
Hello,
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