One developer, one product

Dual Internet is built and supported by Anurag Sinha. No investors, no growth targets, no roadmap dictated by anything other than what people who use it ask for. That has trade-offs in both directions, and this page is honest about both.

Why it exists

It started as a routing table full of hand-written entries

The setup was ordinary: fibre that was fast but occasionally unstable, and a second line that was slower but dependable. Windows picked one by interface metric and ignored the other, so the second line sat there earning nothing while a game update ruined a call on the first.

The workaround was route add and a text file of interface indices. It worked until a DHCP lease renewed, or Wi-Fi reconnected, or a CDN returned a new address — at which point the entries were quietly wrong and the only symptom was something feeling slow. And it could never do the thing actually wanted, which was this application here and that one there, because the routing table has no idea what a process is.

The filtering platform does know. That is the whole product: the mechanism that can express per-application routing, wrapped in something you would trust with your machine's routing table — with a snapshot, a restore, and a rule list you can read.

the file that started it
# routes.txt — DO NOT LOSE THIS
# if=14 is the LTE dongle (check with netsh!)
# if=8  is fibre, usually

route add 142.250.0.0 mask 255.255.0.0 10.24.0.1 if 14
route add 104.16.0.0  mask 255.240.0.0 10.24.0.1 if 14

# 2024-11-03: broke again after router reboot, if= changed
# 2024-11-19: steam ignores all of this anyway
# 2025-01-08: there has to be a better way

How it is built

Six things that are not negotiable

These are the decisions that shaped the product. They cost features occasionally, and that is the intended trade.

Reversible by construction

Nothing touches the routing table without a snapshot first. Restore runs on exit, on crash recovery and on uninstall. If the product cannot be removed cleanly, it has no business being installed.

No telemetry, ever

Not opt-out, not anonymised, not "to improve the product". A tool that watches your network connections has no business reporting anything anywhere. Every outbound request is one you configured.

Documented APIs only

IP Helper and the Windows Filtering Platform, both used as documented. No undocumented calls, no patching, no driver of our own. It survives Windows updates because it is not relying on anything Microsoft did not intend.

Limits stated plainly

The honest limits section exists because a tool that overstates what it can do wastes your money and your evening. Existing connections do not move; two lines do not become one faster line.

Scriptable first

Every capability is reachable from the window; scripting surfaces are planned rather than shipped. Objects out, stable exit codes, --json everywhere. If it can only be done by clicking, it is not finished.

Buy once, own it

A perpetual licence, because software that stops working when a payment stops is a rental. The version you bought keeps running whatever happens to the business behind it.

Under the hood

What it is made of

Boring choices on purpose. Every one of these is something that will still be maintainable in five years.

Runtime

.NET 8 LTS, bundled in the installer so there is no prerequisite to chase.

Interface

WPF with MVVM. Native Windows widgets, no embedded browser, no 200 MB download.

Routing

IP Helper via P/Invoke for the forwarding table, WFP for per-process and per-port decisions.

Storage

SQLite. One file, no server, no schema you cannot inspect with any tool you like.

Scripting

None yet. A CLI and a PowerShell module are planned; neither is in this release.

Testing

xUnit with FluentAssertions for the rule engine and route calculation; manual verification for real-network behaviour.

Why not cross-platform, or a web interface?

Because the entire product is Windows kernel networking APIs. A cross-platform abstraction over WFP and Linux policy routing would be a lowest-common-denominator version of both, and a web interface would mean shipping a browser engine to render a list of processes. Native is smaller, faster, and honest about what it is.

What independence gets you

  • Support replies come from the person who wrote the code, so you never get escalated to someone who has to go and ask.
  • No pressure to add a subscription, a cloud account or an upsell in the interface.
  • A specific, well-argued bug report can be fixed within days rather than entering a quarter-long planning cycle.
  • Nobody is going to acquire this and shut it down.

And what it costs you

  • Support is business hours in one timezone. There is no follow-the-sun rota.
  • The test matrix is a handful of machines and adapter combinations, not a lab. Unusual hardware may need a round trip.
  • Features arrive one at a time. The queue is real but undated, and I would rather not pretend otherwise.
  • One person is a single point of failure — which is why the licence is perpetual and offline-validated, so nothing depends on this business continuing.

Questions are welcome

Technical, commercial or sceptical. If something on this site does not add up, say so and it gets fixed or explained.