Guides and tutorials

Game traffic on fibre, downloads on the second line

The problem with a big game update is not the bandwidth, it is the queueing. A saturated uplink adds tens of milliseconds of buffer delay to everything sharing it, which is exactly what a match server punishes. Moving the download rather than the game is the trick: the download does not care about latency, and the game barely uses bandwidth.

Rules name an executable, so this works when the launcher and the game are different programs — which is the usual case. The launcher does the downloading; the game does the playing.

Setting it up

1. In Applications, find the launcher (Steam, EpicGamesLauncher, Battle.net). Select it, choose your second line as the connection, and press Assign.
2. Find the game’s own executable and assign it to the fibre line. If you are not sure which executable that is, launch the game and look in Processes — it shows what is actually running.
3. Press Apply all, then restart both. Filters only affect connections opened after they exist.
4. Save the pair as a profile called Gaming so you can switch back and forth in one click.

Confirming it worked

Start a download and watch Activity: the throughput should appear on the second line, not the fibre one. Both rules should read Enforced in Rules.

Corporate VPN without tunnelling everything

Most corporate VPN clients are all-or-nothing: connect, and every packet on the machine goes through the tunnel, including a video call with your family and a 400 GB game download. Split tunnelling on the client side is often disabled by policy, and rightly so — but that policy is about company traffic, not yours.

A VPN adapter with its own gateway is just another connection as far as this app is concerned, so you can put the work applications on the tunnel and leave everything else direct. Nothing here weakens the VPN: traffic you send through it still goes through it.

Setting it up

1. Connect the VPN first, so its adapter appears in Adapters with an address and a gateway. If it shows as not routable, the client has not finished connecting.
2. Assign the work applications — the internal tooling, the corporate mail client — to the VPN adapter.
3. Assign the applications you want kept off it — the personal browser, the game launcher, the conferencing client — to your ordinary connection.
4. Save it as a Work profile, and give the profile a weekday schedule if you want it to arrange itself in office hours.

DNS is separate, and this app does not manage it

A split like this can resolve badly: an internal hostname queried through your home resolver will not resolve at all. This application does not configure DNS — each adapter keeps whatever resolver Windows gave it. Set the corporate resolver on the VPN adapter in Windows network settings, and check with Resolve-DnsName internal.corp.example.com.

Protecting a metered line from bulk traffic

When the second line is a hotspot or a capped LTE plan, the goal inverts: you are not trying to use it, you are trying to make sure nothing large wanders onto it. Windows respects its own metered flag for some system traffic, but third-party applications largely ignore it.

Setting it up

1. Assign the known offenders — the backup agent, the torrent client, the game launcher — to your unmetered connection. Pinning them there is what keeps them off the meter, because a confined application cannot wander.
2. Consider isolating the metered adapter as well (select it in Adapters and press Isolate). That raises its interface metric so the rest of the system treats it as a last resort, which catches general traffic you have not written a rule for.
3. Save it as a profile so you can turn the whole arrangement on when you tether and off when you are home.

Overnight instead of never

If the cheap hours are what you are after, make two profiles rather than one rule: a daytime profile that pins the backup agent to the unmetered line, and an overnight profile that does not. Give the second a 02:00–06:00 window and the scheduler will swap them for you.

One caution before running a speed test on a metered adapter: it moves real data. Run it deliberately, not out of curiosity, when an allowance is involved.

Isolating a stream upload

Live encoding is unusually fragile. A sustained upload wants a stable share of the uplink, and anything else that uploads — a cloud sync finishing, someone else’s video call, a torrent seeding — takes it away in a way the encoder can only respond to by dropping bitrate.

Setting it up

1. Assign the encoder (obs64, or whatever you use) to the line you want it to own.
2. Assign the other heavy uploaders — the cloud sync client, the torrent client, the browser — to your other line. This is the half people skip, and without it isolating the encoder achieves nothing, because everything else is still sharing its uplink.
3. Save it as a Streaming profile. Activate it before you go live and switch back afterwards — one click each way.

There is no trigger that arms a profile when the encoder launches, so this is a deliberate switch rather than an automatic one. If your streams are scheduled, a daily window on the profile does the same job.

Profiles that switch themselves on a schedule

A schedule belongs to a profile, not to a rule. You build the rule set you want, save it as a profile, then give that profile a daily window. When the window opens the profile is activated for you; when it closes, its enforcement is cleared.

Setting it up

1. Build the rules you want active during the window, then go to Profiles and press Save current. Name it for the situation — Work, Overnight — rather than for the rules inside it.
2. Select the profile and set its schedule: a start time, an end time, and which days it applies to (every day, weekdays or weekends).
3. Enable the schedule. The status bar tells you when a scheduled activation happens, and you get a tray notification if the window is hidden.

Windows that cross midnight

22:00 to 06:00 is treated as one overnight span rather than an impossible one, so an overnight download profile works the way you would expect. The days you select are the days the window starts on.

Two things to know

• The app has to be running. The scheduler lives inside it, not in a a service — there is none. Turn on Start with Windows and Start minimised so it is there from sign-in without a window appearing.
• Activation is a single transaction. The previous profile’s enforcement is torn down and the new set applied together, so you never sit in a half-applied state. Failures are reported with a reason rather than passing silently.

Deploying to a fleet from one JSON file

The shape that works today: install silently, then hand every machine the same exported profile. A profile carries its rules and its schedule, so one file is the whole configuration.

1 — Install silently

It is a standard per-machine MSI, so the usual switches apply. There are no custom properties: the licence key and the profile are supplied afterwards, not at install time.

msiexec /i "\\deploy\dualnet\DualInternet-1.0.0-x64.msi" /qn ^
  /l*v "%TEMP%\dualnet-install.log"

2 — Author the profile once

Build the rules on one reference machine, save them as a profile, then Export it to JSON. Put that file on your share. The export contains a schema version, the profile name and schedule, and one entry per rule with the process name, its executable path and the adapter name.

3 — Import on each machine

On each machine, Import the file and activate the profile. A name collision gets a suffix rather than overwriting, so importing twice never silently replaces what was already there.

There is no command-line interface or PowerShell module in this release, so this step is performed in the application rather than scripted. If unattended convergence is a hard requirement for your rollout, say so when you get in touch — it is the main thing driving the scripting work.

Adapter names differ across machines

This is the thing that catches fleets out. A profile naming Ethernet will not match the laptop where the dock enumerates as Ethernet 2, and rules whose adapter cannot be found will not be enforced — the Rules list will say so rather than failing quietly.

Either standardise adapter names during imaging, or keep one exported profile per hardware model. Checking the Rules list after import is worth building into your rollout: it is the fastest way to catch a name mismatch on a machine you cannot see.