Hardware Check
-
OK.. so anything behind your pfSense (internal network) connected via network switches has nothing to do with speeds. The internal network runs off your internal network switches. You can have 10Mbps or 100Mbps or 1000Mbps/Gibabit network and it won't tax your pfSense CPU as the data is ignored and only WAN data is processed.
What if you wanted the internal networks to be isolated with limited connectivity and utilize the pfsense firewall to do that? Wouldn't that still get processed by the CPU? Admittedly that would not be as taxing as WAN side processing involving NAT/Snort/VPN/etc. but it still needs to be considered, right? Or is it insignificant enough to be "lumped in" with the rest of the load?
-
OK.. so anything behind your pfSense (internal network) connected via network switches has nothing to do with speeds. The internal network runs off your internal network switches. You can have 10Mbps or 100Mbps or 1000Mbps/Gibabit network and it won't tax your pfSense CPU as the data is ignored and only WAN data is processed.
What if you wanted the internal networks to be isolated with limited connectivity and utilize the pfsense firewall to do that? Wouldn't that still get processed by the CPU? Admittedly that would not be as taxing as WAN side processing involving NAT/Snort/VPN/etc. but it still needs to be considered, right? Or is it insignificant enough to be "lumped in" with the rest of the load?
Yup.. as the internal network switches handle all the internal routing.
-
Yup.. as the internal network switches handle all the internal routing.
They won't if, as he says, he actually wants them routed/firewalled (e.g., each color in his picture on a different VLAN)?!
-
If I am not mistaken, you want Snort but you do not say the number of users behind pfSense. I would recommend i5/i7 or higher like Xeon if you have a large user base. i3 will still be fine for 10-40 users. for 50+ I would go for an i5. For 100+ i7 and 200+ definitely a Xeon. This config is just for Snort as it will hog CPU cycles for processing all the connections coming in and going out the WAN. Plus if you add snort for LAN then it will strain the CPU even further.
Correct me if I am wrong, but isn't snort still largely single threaded? I know thats one reason I am looking at bro a lot harder lately. (the main reason I think snort will soon be utter crap for regular users sounds a lot like cooking oil)
If it is, the difference between i3/5/7/xeon is almost immaterial and you probably want the most recent core with the highest clockspeed. Going from nehalem –> sandy bridge -> ivy bridge -> haswell is roughly 5~10% gain per step given same clock.
(not going to nitpick cache sizes or memory channels, but snort doesn't seem to care much compared to say, video encoding)From this perspective a nice cheap desktop haswell core will beat a dual socket sandy E5 xeon that costs 10 times as much.
(can't find the cheap single socket ivy xeons yet, though if you have 2k+ to burn enjoy 8-12 cores per socket)Also, i5/i7 perform identical to same generation non-HT/HT E3 xeons respectively, just no ECC and maybe VT-d.
-
What if you wanted the internal networks to be isolated with limited connectivity and utilize the pfsense firewall to do that? Wouldn't that still get processed by the CPU? Admittedly that would not be as taxing as WAN side processing involving NAT/Snort/VPN/etc. but it still needs to be considered, right? Or is it insignificant enough to be "lumped in" with the rest of the load?
If you have multiple 'internal' interfaces segregating your network then that traffic is indeed processed and uses almost as much CPU as WAN-LAN traffic (assuming no NAT). It's not at all insignificant. That's why I asked about it.
The diagram doesn't show any switches so it's hard to say quite what is intended.
Steve
-
My internal network activity is many times close to terabytes. Especially during weekend backups. Have 4 separate interfaces out of which 3 are heavily used. I barely see any CPU spikes. I do see my managed switch getting hammered.
-
Is your switch layer 2 or 3? If it's layer 3 then it's handling all the routing most likely. If it's layer 2 then pfsense has to handle all the routing. I guess that's really the question the OP needs to answer, is their switch layer 3 (or do they have a separate router to handle the layer 3 duties)?
-
Layer 2
-
Terabytes per what, though?
So you're saying you're generating gigabits of routed throughput (i.e., between subnets – or are the interfaces just bridged?), and your pfSense box is near idle while your L2 switch is busy? That just seems… wrong. Even cheap switches should be able to forward at line rate without breaking a sweat.
-
I agree, traffic between any two interfaces is filtered by pf. Traffic not involving WAN probably isn't NATed and probably not subject to Snort etc. The only way this isn't true is if you've disabled the firewall. Even bridged interfaces are filtered.
Steve
-
I think you could avoid filtering traffic that is just forwarded between bridge members by setting net.link.bridge.pfil_member=0 and net.link.bridge.pfil_bridge=1, but yeah, pfSense seems to be set up the other way around by default.
-
Yes, the default is a filtering bridge. However I believe I read that even with bridge member filtering disabled there is still some processing takes place. Can't find that now of course. ::)
Steve
-
Terabytes per what, though?
So you're saying you're generating gigabits of routed throughput (i.e., between subnets – or are the interfaces just bridged?), and your pfSense box is near idle while your L2 switch is busy? That just seems… wrong. Even cheap switches should be able to forward at line rate without breaking a sweat.
I have a Netgear GSM7248v2 48-port switch. Typical data transfers are between 20 -28 MB/sec across the subnets and each subnet is on it's own NIC. I wouldn't say the pfSense CPU is near idle.. but it's barely even noticeable. It has to be doing some processing but I have 2 physical Xeon CPUs and I suppose its a walk in the park for them.. ;)
-
Oh, OK, I thought we were talking about pushing throughput close to wire speed; less than 30MB/s isn't exactly what I'd consider "hammering" a gigabit switch.
-
What if you wanted the internal networks to be isolated with limited connectivity and utilize the pfsense firewall to do that? Wouldn't that still get processed by the CPU? Admittedly that would not be as taxing as WAN side processing involving NAT/Snort/VPN/etc. but it still needs to be considered, right? Or is it insignificant enough to be "lumped in" with the rest of the load?
If you have multiple 'internal' interfaces segregating your network then that traffic is indeed processed and uses almost as much CPU as WAN-LAN traffic (assuming no NAT). It's not at all insignificant. That's why I asked about it.
The diagram doesn't show any switches so it's hard to say quite what is intended.
Steve
Tanks for your answer. The networks will be splited in different subnets to different nic port on the pfsense.
-
Oh, OK, I thought we were talking about pushing throughput close to wire speed; less than 30MB/s isn't exactly what I'd consider "hammering" a gigabit switch.
Well 30MB/sec on each subnet. I have 2 NAS and they run backups at nights.. and they coincide with data transfers at some point. So the switch is working on 3 subnets at a time.. sometimes with smaller files it gets to 50-60MB/sec on one subnet alone. So techincally its handling lets say 30 + 50 + 60 MB/sec simultaneously.
-
Mine is rocking at about 4Mbps all day and night…
Reliably too ;D
