From 1.1.29, Korthveil compares every live connection with what your configuration says should happen to it, and ends the connections a change left on an old path. This guide shows where to see it, when it happens by itself, and how to use the fastest tunnel mode of a gateway group.

Why old connections matter

A firewall decides a connection's path and its address translation (NAT) at its first packet. Later changes do not move a connection that is already open:

A new route (for example the TVs through a VPN): open connections keep their old line. Their packets may even go into the tunnel with the wrong address, and the VPN drops them, so apps hang until they give up.
A rule that blocks something, or a schedule that starts (for example a night block): connections that are already open stay open, because the firewall accepts established connections before it checks the rules.
A gateway group that switches tunnels: devices end up split between the old and the new tunnel.

Clearing ends exactly those connections. The device notices at once and opens new ones, which follow the current configuration. A playing video rebuffers once.

What Korthveil does by itself

When	What is cleared
A commit with Clear old connections the change affects ticked (the default in the console)	Connections that the change moves to another path, translates differently, or no longer allows
A schedule starts or ends (checked every minute)	Connections that the schedule now blocks or routes elsewhere
You isolate a device	The device's connections to the internet (its LAN connections stay)
A gateway group switches (in both directions)	The connections left on the old member, when the group's Clear old connections when the group switches is on (the default)
A rollback (the safety timer, or Restore)	The same, back again

Only connections that were fine before and are wrong after are cleared. Connections Korthveil cannot judge, such as the firewall's own connections and your console session, are never touched. Every clear is written to System › Audit log with the count and the reason (actor schedule, isolation, failover, or your name).

Commit: the option and the count

Review and commit shows the option next to the safety rollback, with the number of connections the change would clear now:

Review and commit: Clear old connections the change affects

After the commit, the page shows how many were cleared and a Verify this change panel with the connections of everything you just changed.

Monitoring › Traffic verification

The traffic watcher: for each rule, port forward, source NAT, policy route and gateway group, the live connections it decides, with expected → actual for each step: the rule, the destination NAT (port forward), the route, the outgoing line or tunnel (egress), and the source NAT. Refreshed every 10 seconds.

Traffic verification: a connection a new night block now denies

Scope: all traffic, the last change, or one route, group, rule or NAT rule; Address narrows it to one device.
Counts: ok (green), mismatching (red), unknown (grey).
The flow picture follows source → rule → NAT → egress; mismatching paths are red.
The table shows the verdict per connection: wrong path (it leaves through another line than its route says), wrong NAT (another port-forward target), or now denied (no rule allows it any more), with the reason under it.
Clear mismatching (per item) or tick connections and Clear selected. Operators and administrators can clear; unknown connections never get a box.

Policy routing: Clear connections by hand

Each policy route and each gateway group has an eraser button (Clear connections): it ends that route's or group's connections that are not on the current path.

Policy routes and gateway groups with the Clear connections button

The fastest tunnel (gateway groups)

A gateway group can carry the traffic three ways:

Failover: one at a time, in order — tier 1 while it answers, then tier 2, and so on.
Load balance — every healthy member carries a share.
Fastest — the healthy member with the lowest average ping carries the traffic.

A fastest group: margin, hold time, last resort, and clearing on switch

Settings of a fastest group:

Switch margin (default 20 ms) and Hold time (default 120 s): the group moves to another tunnel only when that one has been at least the margin faster for the whole hold time, without a break. Each switch gives the devices a new public address (streams rebuffer, and a streaming service that sees an address change may ask questions), so the group does not chase small differences. A tunnel that goes down is replaced at once.
Last resort (per member): mark the internet line as the last resort. It is used only while no tunnel answers, even though its ping is the lowest (no VPN in between). With the kill switch on instead, nothing is sent outside the tunnels.
The groups table shows each member's current and average ping (up 6.3 ms (avg 6.5 ms)) and the active member; hover over active for the reason of the last switch (for example wg1 32 ms faster than wg0 for 120 s).

Not for tunnels of one VPN account: a fastest group keeps every member connected to measure its ping. Providers such as NordVPN and IPVanish allow one connected tunnel per account, so for several tunnels of one account use Failover with One tunnel per provider account (or Only the active tunnel) under Connected tunnels instead (see Send your TVs through a VPN).

Example (home network): NordVPN Seattle answers in about 6 ms and Portland in about 28 ms, so Seattle carries the TVs. If Seattle becomes slower than Portland by 20 ms for two minutes, the TVs move to Portland, their old connections are cleared, and they move back the same way.

The pictures of this guide are from the test firewall (version 1.1.29) with example data.