Daniel's been thinking about the old pre-fiber days — DSL bonded with cellular, two Zoom calls bringing the whole thing down, YouTube uploads scheduled around his wife's bedtime like some kind of network curfew. And it got him wondering: we talked about QoS before, rationing bandwidth inside a network, but what he really wants to know is whether you can automate the whole thing. Identify that a device is a NAS, recognize that the living room client is a Smart TV, and then build a bandwidth allocation plan around when people are actually asleep — not manually scheduling every appliance, but teaching the router to do it. He's asking specifically about OPNsense — plugins, built-in tools, or standalone utilities a home labber or small business could use to make this real. So today we're looking at automated QoS — not just the theory, but how you'd actually build a schedule-aware network.
The thing that jumps out at me from Daniel's setup is that he was already doing QoS — just with a human in the loop. He was the scheduler. He knew the NAS sync had to wait until after Hannah went to bed, so he configured it that way manually. What he's asking is whether we can take that human judgment and encode it once, then let the router execute it forever.
The router as a butler who knows when you're asleep and stops the backups from waking the Netflix.
Well, not exactly, but that's the image. And the answer is yes, you can do this, but the way you get there is less polished than most people expect. Let's start with what QoS is actually doing under the hood, because the mechanism matters for the automation part.
Go on then.
QoS doesn't make your internet faster. That's the first thing to get straight. If you've got a hundred-megabit pipe, QoS does not turn it into a hundred and fifty. What it does is decide who goes first when the pipe is full. Think of it like a bouncer at a club — the club still holds the same number of people, but the bouncer decides that the VIPs get in before the line of tourists. Your total bandwidth is fixed. QoS just reorders the packets.
And the bouncer's rulebook is what we're talking about automating.
Right. The classic implementation is the token bucket algorithm — you've got a bucket that fills with tokens at a fixed rate, and each packet needs a token to leave. If the bucket's empty, packets wait. You can give different buckets to different traffic types, and that's how you create priority classes. But here's the gap Daniel spotted: most QoS setups are static. You configure a rule that says voice traffic always gets priority, bulk downloads always get deprioritized, and that rule runs forever. It doesn't know it's 10 PM and everyone's settling in to watch a movie.
Which is exactly the problem. Real life has rhythms. Work hours, sleep hours, the sacred evening streaming block. A static rule set doesn't know the difference between a Tuesday afternoon and a Saturday movie night.
And that's where time-based QoS comes in — rules that change based on the clock, not just the traffic type. This is the automation layer Daniel's asking about, and it's not a standard feature in most router interfaces. You have to build it yourself.
So let's get into OPNsense, since that's what Daniel asked about. What's it actually got under the hood for this?
OPNsense uses something called the dummynet framework, which comes from FreeBSD's ipfw — the IP firewall. Dummynet is a traffic shaper that's been around for decades, and it works by creating pipes. A pipe is basically a virtual link with a configured bandwidth. You create a pipe that matches your actual WAN connection — say, a hundred megabits down, twenty up — and then you attach queues to that pipe for different traffic classes.
Pipes and queues. Sounds like plumbing.
It is plumbing, honestly. The pipe is the total capacity, and the queues are the different faucets. You can say video streaming gets a queue with a minimum guaranteed bandwidth and a maximum ceiling, while bulk downloads get a queue with a lower minimum and can only use whatever's left over. The official OPNsense documentation has a how-to called Reserve Dedicated Bandwidth that walks through exactly this — setting up a pipe for the WAN interface, then creating child queues for things like VoIP, gaming, streaming, and bulk traffic.
And this is all in the GUI?
The basic setup is, yes. You go to Firewall, then Shaper, and you configure pipes and queues with weight values and bandwidth limits. But here's the thing — and this is where Daniel's question gets interesting — OPNsense has two different traffic shaping tools. There are limiters, which are simple bandwidth caps. You create a limiter, assign it a maximum speed, and attach it to a firewall rule. Done. But limiters don't do hierarchical queuing — they can't say streaming gets priority over backups within the same pipe. For that you need the full shaper, which uses dummynet pipes and queues with weights and scheduling algorithms.
So limiters are the blunt instrument, shaper is the scalpel.
That's it exactly. And for what Daniel wants — a schedule-aware system that knows the difference between a Smart TV streaming Netflix and a NAS running a backup — you need the scalpel. You'd create a pipe for your total WAN bandwidth, then child queues for different traffic classes. Video streaming gets a queue weighted at, say, eighty percent during evening hours. The NAS backup queue gets five percent during the day and eighty percent overnight.
Hold on.
You said during evening hours and overnight. But you also said the shaper rules are static.
They are. And that's the automation gap. OPNsense does not have a built-in scheduler GUI for toggling shaper rules based on time of day. There's no page where you click a checkbox and say apply this queue configuration from 8 PM to midnight. You have to build that yourself.
So how?
Cron. OPNsense has a built-in cron service under System, Settings, Cron. You can define jobs that run shell scripts at specific times. And since the shaper rules ultimately become ipfw rules in the underlying FreeBSD system, you can manipulate them from the command line. The tool for that is called configctl — it lets you trigger OPNsense services from a script. You'd write a shell script that modifies the shaper configuration and then reloads it, and you'd schedule that script to run at, say, 10 PM and again at 7 AM.
So at 10 PM, a script fires that says the NAS is no longer throttled, and at 7 AM, another script throttles it back down.
There's a thread on the OPNsense forum — topic four seven three one three — where users are doing precisely this for Plex traffic. Someone wanted to make sure their Plex server always got priority during evening streaming hours. The approach they landed on was creating a shaper rule that gave Plex traffic a guaranteed chunk of bandwidth, then using cron to toggle that rule on at 6 PM and off at midnight. The script deletes the NAS from the high-priority queue at night and re-adds it in the morning.
What does that script actually look like?
At its simplest, you're manipulating ipfw tables. You'd have a table that lists the IP addresses of high-priority devices — your Smart TV, your streaming box. The cron job at 8 PM adds the TV's IP to that table. The cron job at midnight removes it. Something like ipfw table one add the TV's IP address, or ipfw table one delete the NAS's IP. Then your shaper rules reference that table, so the priority shifts automatically when the table contents change.
And this requires that every device has a static IP.
Yes — and that's a prerequisite that trips people up. If your NAS gets a new IP from DHCP every few days, your cron script is pointing at a moving target. You need DHCP reservations — also called static mappings in OPNsense — so that each device always gets the same IP. That's step one, before you even touch the shaper. Identify every device you want to manage, assign it a permanent IP, document what it is and what it does.
Label the zoo before you build the cages.
Right. And that's the part nobody talks about in the shiny how-to guides. The technical plumbing works fine, but the upfront classification work is manual and tedious. You have to know your network. You have to know that the device at dot one hundred is the NAS, dot one oh five is the living room TV, dot one ten is the office computer that runs backups at 3 AM. If you skip that step, your elegant cron automation is just shuffling rules against devices you don't understand.
So Daniel's vision of identify this is a NAS, this is a Smart TV — the identify part is still on him. The router doesn't know what a NAS is. It knows MAC addresses and IP addresses.
That's the core limitation, and it's worth sitting with for a second. When Daniel says identify that this is an NAS, he's imagining the router doing the classification. In practice, he's the one doing the classification, and the router is just executing his decisions on a schedule. The automation is in the schedule, not in the discovery.
But that's still valuable, right? Do the classification once, write the cron scripts once, and then never think about it again.
And that's the promise of this approach — it reduces the cognitive load of network management to near zero, once it's set up. No more planning uploads around bedtime. No more remembering to pause the sync before starting a movie. The network just knows that at 8 PM, streaming gets the pipe and everything else gets the leftovers.
What about failure modes? What happens when the cron script doesn't run?
That's the second thing that trips people up. Cron is reliable, but it's not infallible. If the router reboots at 9:55 PM and comes back up at 10:02 PM, your 10 PM cron job might have been missed entirely. Now your NAS is still throttled during prime streaming hours, or worse — your streaming traffic is throttled while the NAS runs wild. I've seen forum posts where someone's backup saturated their connection during a family movie night because the cron job silently failed.
A silent failure that announces itself with buffering.
And the fix is defensive scripting. You don't just toggle rules — you check the current state first. Your 8 PM script doesn't blindly add the TV to the priority table; it checks whether it's already there, removes it if it is, then adds it fresh. And you add a fallback: if the script can't determine the current state, it defaults to a safe configuration — maybe everything gets equal priority rather than the NAS getting everything.
So you're writing error handling into your network management. This is starting to sound like a small software project.
It is. And that's the honest answer to Daniel's question. Yes, you can automate QoS with OPNsense. The tools exist. But you're not clicking through a friendly wizard — you're writing shell scripts, testing edge cases, and maintaining a small codebase that runs your home network. For a home labber, that's part of the fun. For a small business, it's a legitimate maintenance burden.
Let's broaden out. Daniel asked about tools beyond OPNsense too. What else is out there?
The broader ecosystem is interesting because almost nobody has solved this elegantly. pfSense, which is OPNsense's closest relative, has a similar traffic shaper — it can use either ALTQ or dummynet depending on the version — and it also relies on cron for any kind of time-based scheduling. Neither platform has a first-party time-of-day QoS GUI. It's a feature gap that's been discussed in forums for years and never filled.
Why not?
I think because the people who need it are a niche within a niche. Most home users don't configure QoS at all. Most businesses that need QoS have static requirements — voice always gets priority, period. The subset of users who want their network to behave differently at 8 PM than at 8 AM is small, and they tend to be the kind of people who are comfortable writing cron scripts anyway.
The market solving the problem by not solving it, because the people with the problem are also the people with the solution.
Now, there's another approach worth talking about, and it's the one that doesn't use schedules at all. OpenWrt has something called SQM — Smart Queue Management — that uses an algorithm called Cake, which is built on top of fq_codel. The idea is fundamentally different from what we've been discussing. Instead of setting static priority rules, Cake dynamically manages bufferbloat in real time. It watches the queue, identifies which flows are causing latency, and adjusts on the fly.
So it's adaptive rather than scheduled.
Right. And it's brilliant at what it does — if your problem is that a big download makes your video call stutter, Cake fixes that without any configuration. You turn it on, set your bandwidth limits, and it just works. But it's time-agnostic. It doesn't know or care that it's 8 PM and you'd rather the Netflix packets go first. It treats all traffic fairly in the moment, which means during peak hours, your streaming and your backups are competing on equal footing.
Which is the opposite of what Daniel wants. He wants the backups to lose during movie time, even if they're the only thing running.
Cake's fairness is a feature for most use cases, but it's a bug for Daniel's scenario. He wants unfairness — deliberate, scheduled unfairness that favors entertainment in the evening and bulk transfers overnight.
So Cake is the wrong tool for this job.
As a standalone solution, yes. But you could layer it. You could use OPNsense's cron-based shaper for the time-of-day priority decisions, and then run Cake or fq_codel within each priority class to manage bufferbloat. The shaper decides who gets the bandwidth; Cake makes sure that within each class, no single flow starves the others.
Two layers of traffic management. Now we're really building something.
We are, and this is where home lab networking starts to look a lot like enterprise networking. The principles are the same — classification, prioritization, queuing, scheduling. The tools are just smaller and cheaper.
You mentioned ntopng earlier — what's that bring to the table?
ntopng is a network monitoring tool that can integrate with OPNsense through a plugin called os-ntopng. It does deep packet inspection — it looks at traffic flows and classifies them by application. It can tell you that this stream of packets is Netflix, this one is a Windows update, this one is a Zoom call. That classification data is incredibly useful for understanding what's happening on your network.
But can it drive the automation?
Not natively, no. ntopng can show you that your NAS is saturating the uplink with a backup at 8:15 PM, but it can't automatically throttle that backup. It's a monitoring tool, not a control tool. You'd need something else to take ntopng's classification data and feed it into the shaper rules — and that something else doesn't really exist as a packaged product. You'd be building it yourself.
So the classification piece — the identify this is a NAS part of Daniel's question — ntopng can do that. But the act on it part still requires cron and shell scripts.
Yes. And there's a research-grade tool called nDPI that's even better at classification — it's the engine underneath ntopng, actually — and there's experimental work on using machine learning with nDPI to recognize traffic patterns automatically. The idea is that the system learns this device streams video every evening at 8 PM, so it should be prioritized then. But that's not production-ready for a home lab. It's the kind of thing you read about in papers, not something you install from a package manager.
The cutting edge is still cutting.
It is. And honestly, for the home lab use case Daniel's describing, the cron-based approach is probably the right answer for the foreseeable future. It's simple, it's reliable if you script it defensively, and it does exactly what he wants — it encodes his family's schedule into network policy.
Let's talk about the daylight saving time problem.
Oh, that's a classic. Cron on Unix systems typically runs on the system clock, and if your system clock shifts by an hour twice a year, your carefully scheduled 8 PM priority shift suddenly happens at 9 PM or 7 PM. For two weeks every spring and fall, your network is operating on the wrong schedule.
And nobody notices until the buffering starts.
Right. The fix is to run cron on UTC — Coordinated Universal Time — which doesn't observe daylight saving. Your 8 PM in local time becomes a fixed UTC hour, and the schedule stays consistent year-round. But that means your cron expressions are in UTC while your brain is in local time, and you have to do the mental conversion every time you adjust the schedule.
Another small maintenance burden.
Another one, yes. And it's the kind of thing that makes this whole approach feel less like a consumer product and more like a system administration project. Which, for the audience that listens to this show, is probably fine. But it's worth being honest about.
So if Daniel wanted to actually build this, what's the shopping list?
An OPNsense box — could be a repurposed PC, a Protectli vault, one of those little fanless boxes with multiple Ethernet ports. DHCP reservations for every device you want to manage. A documented list of which IP belongs to which device and what it does. A set of shaper pipes and queues configured for your WAN bandwidth. And then a handful of cron scripts — probably three or four — that toggle the queue assignments based on time of day. The scripts live in the home directory of the root user, they're called from cron, and they log their output so you can debug when something goes wrong.
And the whole thing probably takes a weekend to set up and tune.
A weekend if you know what you're doing. Longer if you're learning as you go. But once it's running, you don't touch it except to add new devices or adjust the schedule. That's the payoff — the network just handles it.
Until the power goes out and the router comes back up at the wrong time and your cron job misses its window.
Yes, and that's the real-world failure case. There's a story on one of the forums — I can't remember if it was OPNsense or pfSense — where someone had this exact setup, and a power outage at 9:58 PM meant the 10 PM script never ran. The NAS spent the entire night in throttled mode, the backups didn't complete, and the next day's incremental backup tried to catch up during work hours. It cascaded.
A single missed cron job cascading into a day of congestion.
And the fix the user eventually landed on was adding a boot-time script that checked the current hour and applied the correct schedule. So even if the router rebooted and missed a cron trigger, it would still end up in the right state within a few minutes of coming back up. That's the kind of defensive layering you need for this to be truly reliable.
We're building a network that heals itself.
We're building a network that's resilient to its own automation failures. Which is a whole discipline in itself.
Hilbert: We ran a T1 line to a town of three hundred people in Vermont and did exactly this, except the router was a white-box PC running Debian and I edited the ipfw rules by hand over SSH.
A single T1 for three hundred people?
Hilbert: One point five megabits. The whole town. And the priority wasn't Netflix — this was two thousand eight, nobody was streaming anything. The priority was the clinic. They had a telemedicine setup, low-bitrate video, looked terrible, but it meant the doctor in Burlington could see a patient without making them drive two hours. We gave that traffic ninety percent of the pipe between 9 AM and 5 PM.
And everyone else just... waited?
Hilbert: They knew. The librarian figured out the schedule faster than I did. She'd try to watch a YouTube video at 3 PM and get about four frames, then she'd call me and I'd remind her about the clinic. She wasn't mad about it — she just wanted to know when the pipe opened back up. I ended up printing the schedule and taping it to the wall at the library.
You published the QoS policy. Publicly.
Hilbert: It was a small town. Everyone knew everyone's business anyway. Might as well know when the internet was fast.
You mentioned the librarian figured out the schedule faster than you did. What does that mean?
Hilbert: Daylight saving. My cron scripts ran on local time, and twice a year the schedule shifted by an hour. The clinic lost priority at 8 AM instead of 9 AM for two weeks every spring. The nurses never noticed — they were too busy to care about a little buffering. But the librarian noticed. She called me at 8:15 AM one March and said her YouTube was buffering and was the clinic schedule different now. That's how I learned to use UTC.
The librarian was your network monitoring system.
Hilbert: Best one I ever had. She'd call before anyone else noticed anything. I still think about that sometimes — the most reliable part of that whole setup wasn't the scripts or the router, it was a person who paid attention.
And when you moved to UTC, did she notice the schedule had stabilized?
Hilbert: She called to ask why I'd changed the hours without telling her. I said I hadn't changed the hours, I'd fixed the clock. She said that was the nerdiest thing I'd ever said to her. She wasn't wrong.
The approach we've been describing — cron scripts, ipfw tables, manual device classification — you were doing this eighteen years ago on a Debian box.
Hilbert: The tools are fancier now. The problem is exactly the same. One pipe, too many people, and someone has to decide who goes first.
The decision was the clinic. Not because of some technical metric, but because the alternative was a two-hour drive.
Hilbert: That's the part the tools don't capture. The shaper doesn't know why a rule exists. It just knows this IP gets priority. The why lives in a conversation someone had, or a meeting, or a phone call from a librarian. The automation is the easy part. Deciding what to automate — that's where the actual thinking happens.
Daniel's question is ultimately about encoding a family's rhythms into network policy. Who gets the bandwidth when, based on who's awake and what they're doing. That's the same kind of decision you were making for a whole town.
Hilbert: Smaller scale, same shape. Somebody has to sit down and say during these hours, this matters more than that. The scripts just enforce it.
The enforcement layer is fragile in exactly the ways you'd expect — missed cron triggers, daylight saving bugs, devices that change IP addresses. But the decision layer — the part where you decide the NAS waits until everyone's asleep — that's robust. That doesn't break.
Unless you get the decision wrong. What if the clinic had needed bandwidth at 6 PM for an emergency consult?
Hilbert: That happened. Not often, but it happened. I had an override script — a one-liner I could run from my phone that would kill the scheduler and give the clinic everything. Ugly, but it worked. The librarian never called about those.
She knew the difference between a broken schedule and an emergency.
Hilbert: She knew everything. She was the librarian.
Where does this leave Daniel? The tools exist — OPNsense with cron and the shaper, or a Debian box with ipfw if you want to go full Hilbert. The automation is achievable. But it's not plug-and-play, and it probably won't be anytime soon, because the market for this is tiny and the people who want it are the people who can build it themselves.
The open question is whether we'll ever see a router that learns these patterns automatically. Not just classifying traffic by application — ntopng and nDPI can already do that — but actually learning that this household streams video at 8 PM and runs backups at 2 AM, and adjusting QoS accordingly without anyone writing a cron script.
I think we'll get there, but it'll come from the consumer mesh Wi-Fi space before it comes from OPNsense. The companies that make Eero and Google Wi-Fi have the telemetry data to train those models — they can see traffic patterns across millions of households. A single home labber running OPNsense doesn't have that kind of training data.
The future of automated QoS might not be something you configure at all. It might be something your router learns by watching you, the same way your thermostat learns when you're home.
Until then, we've got cron and shell scripts and the satisfaction of building it ourselves. Which, for the kind of person who listens to an episode about traffic shaping on a Saturday, is probably the better outcome anyway.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for keeping the show running, and for the reminder that the best network monitoring system is sometimes a librarian with a phone.
If you want to dig deeper into any of this, the show notes will have links to the OPNsense shaper documentation and the forum thread we mentioned. And if you've built something like this yourself, email the show at show at my weird prompts dot com — we'd love to hear what you learned. We'll be back soon.
