Today I was setting up a two Synnology NAS units to sync using CloudStation over a WAN link. This was pretty easy to set up using Synnology’s QuickConnect feature. But the problem was that we didn’t want the syncing NAS units to bog down the WAN links during working hours, because those WAN links are shared. So we needed to throttle those connections down to a reasonable speed during the day, but let them go as fast as possible at night. Fortunately, my gateway runs pfSense, which is a very capable FreeBSD-based open source firewall and router.
There are loads of forums posts listed on Google where people are having trouble with the Limiter feature in pfSense. The correct configuration of limiters is widely misunderstood, and the documentation is sparse and ambiguous. I hope to clarify some of that here.
Key Issue: Reset The State Tables
Then general instructions for setting up rate limiting for a particular host are to:
- Create a limiter for download, enable it, set a speed on it and save it
- Create a limiter for upload, enable it, set a speed on it and save it
- Create a firewall rule that ties some host(s) to the limiter
- Shazam: it works!
Well, actually, people seems to be split into two groups at this point: those for whom it just works and those for whom it just doesn’t work. I think I know the reason why.
Group One: Shazam! It works!
There are some YouTube videos illustrating these setups. They go like this: Open up speedtest.net, run a speed test. Make pfSense config above for the same workstations, and then open speedtest.net again and voila! The change has taken effect.
Group Two: It Just Won’t Work
I think these people are doing something different, and this is what I was doing. I opened up a bandwidth monitor (e.g. the traffic graph in pfSense), made the limiter config above and applied it to a different host, and checked back on the traffic graph. No change. Whaaaaat?
So here’s the thing. For group one, after the pfSense config, they go back to speedtest, and by that time, they have a new state with speedtest.net. For group two, if the traffic stream they are trying to affect is still streaming, then the state is the same and the limiter will have no effect until they Reset the state tables!
So if you already have a stream of data, such as a NAS that already has a connection to a remote NAS and is uploading, and you create a pfSense limiter and a rule that applies and click on [Apply changes] then the limiter will have effect because it will only affect new states. This is NOT well documented.
Limiting On A Schedule
The above info also ties into the use of scheduling with limiters. You can set a schedule on a limiter, or on a firewall rule. But as we know from above, if we already have a long-term data stream established, then changing a firewall rule will not affect the existing state. Same is true for schedules. If you were to set a schedule on the firewall rule, then you’d have to reset the state tables manually each time the schedule activated or deactivated. Or, you’d have to wait until the connection got dropped and a new connection was established, in which case the rule change would affect the new state.
If you set the schedule on the limiter, then it will be effective right away when the schedule becomes active or inactive. That’s because the firewall rules have not changed. Only the speed of the limiter has changed, and no reset of the state tables is required to make that effective.
If you are setting up limiters that will affect existing connections, then if the firewall rules have changed, then you need to reset the state tables (i.e. re-establish those connections) to affect them. Think of the limiter as a pipe. Once the data is flowing through that pipe, you can affect the speed by changing the bandwidth of the limiter manually or using a schedule.