Send visits to chosen websites, everything from a torrent machine, and the torrent traffic of any device through a WireGuard VPN, with a kill switch: when no VPN tunnel answers, that traffic stops instead of leaving through your normal internet line, so your home address is never shown to those sites or to torrent peers. Everything else keeps using the normal line.

This guide follows the setup of a home network: two NordVPN tunnels (Seattle, then Portland), the websites yts.vg and yts1.mx, a download machine running Transmission (192.168.2.16), and torrent clients on other computers that use the peer port 51413.

At a glance:

The VPN tunnels and their outbound NAT must exist first: see Send your TVs through a VPN, with a fail-safe (Steps 2 and 3).

Can Korthveil recognise torrent traffic by itself?

Not reliably, and no firewall does by addresses alone. Korthveil recognises applications (App-ID) from the names a connection uses: the website name in an HTTPS connection, the HTTP host, and DNS answers. That is how website routing works below. Torrent peers are other people's computers, reached by address and a random port, with no name to recognise: deep packet inspection of the torrent protocol is not part of Korthveil yet.

So torrent traffic is routed by what it reliably has:

• the machine that downloads (everything from it goes through the VPN), and
• the client's peer port: torrent clients send their UDP peer traffic (uTP) and DHT from one fixed port; outgoing TCP to peers uses random ports and needs one more rule (Step 3). Set every client to the same port (Transmission: Preferences › Network › Peer listening port, default 51413; qBittorrent: Options › Connection › Port used for incoming connections; turn off the random port option), and route that port.

Step 1: The websites as one object

Firewall › Aliases & objects › Add address object: name VPN_Sites, and under Entries type the website names, several at once separated by spaces: yts.vg www.yts.vg yts1.mx www.yts1.mx, then Add. Each name is checked at once and shown with the addresses it resolves to now; Korthveil follows them when the site's DNS changes. Add the www. name too: it is a separate name. Save to pending changes.

Shared addresses: many sites sit behind a content network (here Cloudflare: 104.21.x, 172.67.x). Routing a site's address also routes the other sites that happen to share it at that moment. That is harmless for a VPN route: those visits go through the VPN too.

Step 2: A VPN group with the kill switch

Network › Policy routing › Gateway groups › Add gateway group:

• Name: TORRENT_VPN.
• Failover: one at a time, in order.
• Tier 1: wg0 (NordVPN Seattle), monitor 1.1.1.1, down after 6, up after 3.
• Tier 2: wg1 (NordVPN Portland), monitor 1.0.0.1, the same.
• Kill switch: on. Do not add the internet line as a tier: with both tunnels down, the traffic of this group is dropped.

From 1.1.29 you can also choose Fastest instead of the fixed order: the healthy tunnel with the lowest ping carries the traffic.

Step 3: Three policy routes

Policy routes › Add policy route, each with Send via: A gateway group, Gateway group: TORRENT_VPN, from zone LAN:

1. The websites (LAN: VPN_Sites via TORRENT_VPN): source any, destination VPN_Sites, service any. Every device's visits to those sites go through the VPN.

2. The torrent machine (Transmission host: everything via TORRENT_VPN): source the machine's object (here Transmission_Host, 192.168.2.16, with a DHCP reservation), destination RFC1918 with Not these ticked (everything except your own networks), service any. The machine reaches the internet only through the VPN; your LAN, printers and shares stay direct.

3. The torrent port on any device (LAN: torrent port 51413 via TORRENT_VPN): source any, destination RFC1918 with Not these, and two services: TCP with source port 51413 and UDP with source port 51413 (leave the destination ports empty). A torrent client on any computer, set to that port, uses the VPN for its UDP peers (uTP) and DHT, while the computer's other traffic stays on the normal line. Its outgoing TCP peer connections are not caught by this route: see below.

Order: policy routes are checked top to bottom and the first match decides. Move the three routes above broader routes that could match the same traffic first (for example imported routes for "Google & YouTube" or "LAN subnets"). In the example they are #2–#4, under the TV route.

What the port route does not catch (tested on the home network, 2 November 2026): torrent clients send UDP (uTP and DHT) from their peer port, so route 3 carries almost all the data through the VPN (1.66 GB of 1.66 GB in the test). But their outgoing TCP connections to peers use random source ports, so route 3 cannot recognise them: in the test, 52 TCP peer connections left through the normal line with the home address. Close that gap with one of:

• Best: a dedicated address for the torrent machine (route 2): the whole machine, or a second address on the computer that only the torrent client uses (Transmission: bind-address-ipv4 in settings.json, edited while Transmission is closed), or the client in a container with its own LAN address. Then everything the client does, including tracker announcements, is behind the kill switch.
• Good enough for a computer you also work on: a reject rule on the normal line. Firewall › Rules, at the top: from LAN, source the computer, to the internet zone, Out interface the internet line (here enp1s0), service TCP to every port except the ones your other programs use (web 80/443, mail, SSH 22, DNS over TLS 853, and any app-specific port), action Reject, log on. Torrent peers then cannot be reached over the normal line, and the client uses uTP through the VPN instead. Trackers on port 443 still see the home address.

A computer you work on: routing everything from it through a kill-switched VPN takes it offline when the VPN is down. For a computer you also use for work, use the port route (route 3) together with the reject rule, or a second address only for the torrent client.

Step 4: Commit, keep, and check

Review and commit: the network changes list a policy table per route, each through the tunnel (table 2002 dev wg0, …). Commit with the safety rollback on, then Keep these settings. With Clear old connections the change affects ticked (from 1.1.29), downloads and pages already open move to the VPN at once.

The group shows the active tunnel and the kill switch on:

Check it:

• Firewall › Policy lookup: from LAN, the torrent machine's address, a website address or any internet address, TCP 443. The answer names the route (LAN: VPN_Sites via TORRENT_VPN, Transmission host: …) and the source NAT through wg0.
• Firewall › NAT translations, filtered by the machine's address: the translated source is the tunnel's address (10.5.0.2 for NordVPN).
• From 1.1.29, Monitoring › Traffic verification with the route as scope shows every connection of the route with expected and actual tunnel.
• On the machine, a "what is my IP" site in the browser (route 2), or the torrent client's own IP check, shows the VPN's address.

Good to know

• Incoming peers: most VPNs (NordVPN) do not forward ports to you, so other peers cannot connect to your client; downloads still work through outgoing connections.
• IPv6: the group carries IPv4 only. With the kill switch, IPv6 to those destinations is dropped rather than sent outside the VPN, so nothing leaks over IPv6.
• DNS: the devices ask the firewall for names (DNS interception), and the firewall asks upstream over encrypted DNS. Website names in VPN_Sites are resolved by the firewall itself.
• A device using its own encrypted DNS (DNS over TLS on 853, or DNS over HTTPS) may get other addresses for a site than the firewall resolved; if a site still shows your home address, check its addresses in Policy lookup.

The pictures are from the home rack firewall korthmain, 2 November 2026. Addresses of the internet line are not shown.