Hardware

I will be using using generic-pc m0n0wall 1.33 for a large network hosted on a 3.0GHz Intel P4 server. What constraints can be expected? What troubleshooting steps need to be practiced? How can bottlenecks be identified?

Poking around this forum, I have seen documented cases of CPU overload, PCI overload, RAM problems, and accounts of too many open connections. Can the (in)active list of DHCP clients grow to large? Do logs need purged?

Bottom lone: What does an IT admin need to be aware of when deploying m0nowall?

Any insight is appreciated!

I'm of the mindset of using the appropriate tools in the appropriate places.  m0n0wall is my favorite small router OS.  I use it where the hosting hardware isn't large, for reasons of power, budget, or what was simply laying around collecting dust.

In a larger environment you can easily exhaust m0n0wall's default state table, increasing that requires a kernel re-compile.

In a larger environment, using "larger" hardware, pfSense might be your better choice.

Otherwise, hardware specific, there's 2 main types of constraints: throughput and CPU.  CPU will be used for VPN and traffic shaping.  A 3Ghz P4 should be fine for a large amount of VPN traffic (that's VPN "hosted" by m0n0wall, not passing VPN traffic through m0n0wall, that's just regular traffic.)

Throughput issues are usually caused by NICs, busses, or NIC Drivers.  A modern 3.0Ghz P4 machine may have multiple Ethernet ports, if they're "Intel" chips on them, assume that you'll be able to route a lot of traffic with that, possibly up to most of a Gigabit conenction, if that's what the ports are.  If there's a PCI-Express slot you should be able to put in a PCI-Express NIC, possibly with multiple ports, in this situation you won't be affected by the bus speeds.  If standard PCI is your only option for extra ports, expect to be able to host a single Gb interface without too much congestion on the PCI bus, more than that and individual ports may slow down.  10/100 port cards on a PCI bus shouldn't be bus limited untill you get up around 10 ports, assuming they're all saturated with 100Mb of data, which likely isn't happening anyway (and, you still have to get 10 ports physically on there, which means dual or quad port cards, multiple of them.)

Basically, from an IT admin perspective, I use m0n0wall for small situations where I need to cheaply route a small number of machines, such as creating a small Dev network or customer WiFi, or something similarly "small".  I have used it at an old job to provide guest wireless to customers during events, used the captive portal to "authenticate" our guests with a simple password.  Eventually I heard that there was one particular event where a lot of users were using VPN back to their respective companies and it over-ran the state table.  They "upgraded" to pfSense and all was well.  (This was on a Dell PE 2850, so, I think 8GB of RAM, dual P4 Xeon's of some speed in the 2.8Ghz range, 2x onboard BroadCom Gb nics.)

Now, I'm not steering people away from m0n0wall, I run it at home for my main router and I use it for VM isolation all the time, but for "larger" installations, pfSense may be viewed as m0n0wall's big brother.

So, what is a 'large' environment? In my case, this is the largest m0n0 deployment I have implemented based on total number of active and total number of unique clients. Bandwidth is minimal, routed traffic is capped by our ISP at 25Mbps/25Mbps.

I have stress tested the router in question at nearly 100Mbps bidirectional over a period of days, limited to about 6 open connections. It is easy to monitor CPU, memory, and temp. Is there any way to monitor the size of the state table?

I'm not ready to ditch the m0n0 deployment and it's configuration until I'm in in a situation where it is the wrong tool. Simply because I'm not convinced m0n0 is the wrong tool or that pfSense is a better tool.

Our busy season is right around the corner. So far, m0n0 has been a champ at routing our public wifi connection. We see bandwidth pegged at 35 Mbps down nearly all day. QoS and traffic shaping keep the connection snappy for all users. CPU / RAM don't seem to be an issue at the moment.

I am still concerned about exahusting m0n0's state table. Can I manually monitor its size from the WebGUI or automatically measure it with an SNMP tool?

You could go to System>Advanced>Firewall States Displayed, set it to a higher number and check the Diagnostics>Firewall table for the number and listing of connections. I think there is an elegant way of reading the number through sysctl but i don't know the location, if i find it i'll post.

If You are running out of states You might consider lowering the TCP state entry inactive TTL to a reasonable number, but not too low.

I use m0n0wall in the enterprise often.  By enterprise, I mean at least 3 multi state clients with IPsec VPN and multiple LAN connectivity.

The state table limit is a hard limit, but with reasonable expiry, I have not had a problem.  (In one location that have over 1000 nodes local)

CPU is the VPN limit, but unless you have 100 meg fiber, you will be limited by Internet, not CPU.

IO is a problem if you have multiple gigabit links.  If that is the case, consider multihoming key servers...

Revisiting an old subject -

It is fun to see the sheer number of devices that connect to public wifi sites - and the hundreds of connections each makes!

What is the state table hard limit in the Generic PC build of 1.8.1?

I think it is still 30,000.