I use a computer running FreeBSD as my firewall/router, and I thought I'd share some firewall rules I use for prioritizing MULE traffic (among other things) so other outgoing Internet traffic doesn't cause lag. These could probably also be adapted to m0n0wall, since it's FreeBSD-based.
To understand what these rules do, it's important to understand how queues work in FreeBSD's traffic shaper. A queue with 100% priority gets access to the entire pipe. A queue with 80% priority can use the entire pipe if nothing from a higher-priority queue wants it, but will have to relinquish up to 20% of the bandwidth if there's higher priority traffic. This effectively lets us reserve some bandwidth for MULE on an as-needed basis; we're actually letting MULE packets jump in line ahead of packets for other traffic.
I left in some lines where I also route SSH traffic to the high-priority queue, because I thought they helped illustrate how other services can be treated this way.
Here's an excerpt from my /etc/rc.local:
# Load the traffic shaping module:
/sbin/kldload dummynet
# Configure a pipe with our maximum upstream bandwidth.
/sbin/ipfw pipe 1 config bw 320Kbit/s queue 50 gred 0.002/45/50/0.1
# Queue with 100% weight for interactive traffic:
/sbin/ipfw queue 1 config pipe 1 weight 100 queue 50 gred 0.002/45/50/0.1
# Queue with 80% weight for everything else:
/sbin/ipfw queue 2 config pipe 1 weight 80 queue 50 gred 0.002/45/50/0.1
# SSH traffic from me and to other systems:
/sbin/ipfw add 600 queue 1 ip from me to any src-port 22 out via fxp0
/sbin/ipfw add 601 queue 1 ip from any to any dst-port 22 out via fxp0
# MULE:
/sbin/ipfw add 620 queue 1 ip from any to any src-port 6260 out via fxp0
/sbin/ipfw add 621 queue 1 ip from any to any dst-port 6260 out via fxp0
# All other traffic. This must come last.
/sbin/ipfw add 699 queue 2 ip from any to any out via fxp0
Important notes about the above code:
- "fxp0" is the name of the network interface that's connected to the Internet, on my machine. This should be changed to suit your system.
- The "pipe 1 config" line will need to be tuned for your specific connection. The total bandwidth ("bw 320Kbit/s" in the example) has to be no more than your connection can actually support, or packets will be dropped by your upstream router, defeating the purpose. I suggest using a few of the "Internet speed test" sites to get a good estimate of your actual upstream (aka. upload) bandwidth. If you still see high ping times in MULE when the connection is heavily loaded, you may also need to reduce the "queue 50" number to something smaller. (The slower your connection, the more likely you'll need to make the queue smaller.)
- These rules need to come
after the "divert" rule that makes FreeBSD NAT work. Just make sure the rule numbers are higher, and it should be OK.
- Traffic shaping only really works for outgoing data. Obviously there's not much you can do to prioritize what gets sent to you. But for most of us, upstream bandwidth is the limiting factor, anyway.
