Blocking Transmission's incoming port is not a VPN policy. A torrent client opens outgoing connections to peers and trackers, resolves names, and may expose a remote-control listener, and each of those can leave through an interface you did not intend. Work through the five checks in order and treat the firewall rule, not the client's settings, as the boundary. The last two checks are the ones people skip, and they decide whether the guarantee holds when the tunnel drops.

Name the process that owns the transfer

The desktop application and the system daemon run under different accounts, and an owner-based rule follows the account rather than the program name. Find out which one is running before writing any rule. A dedicated service account gives the policy a precise subject, while a desktop user shares its identity with browsers, editors and everything else in the session. Confirm the UID instead of assuming the packaged account name is the one in use.

systemctl status transmission-daemon
ps -o user=,pid=,cmd= -C transmission-daemon

If the account does not exist yet, create it for this purpose and give it nothing else to run. Write the account and UID into the rule comment, because a rule without a subject is a rule nobody can safely edit.

Separate the listener fields from the route

Transmission 4.x documents peer-listen addresses separately from rpc-bind-address, and the difference matters. The RPC setting controls the remote-control listener only, so changing it does not choose a route for peer traffic. Reading the two settings as one is the most common reason a careful-looking configuration still leaks. The same documentation describes a fallback when a peer-listen address is invalid, so an unavailable address is a documented fallback case, not a guaranteed refusal.

grep -E '"(peer-port|rpc-bind-address|bind-address-ipv4)"' /var/lib/transmission-daemon/.config/transmission-daemon/settings.json

Use the client's controls for what they are, and put the guarantee in the firewall. A listener setting can still be worth using, but it does not establish that tracker contact, local discovery or a delegated lookup all leave through the tunnel. When the two disagree, the firewall is the one that decides.

Write the owner match in the right chain

The Netfilter owner-match manual explains how locally generated packets are attributed to the socket file's owning user or group. That attribution does not extend to forwarded traffic, and supplementary-group matching needs an explicit option. Read the manual for the extension you are actually using rather than the first example you find.

iptables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner transmission -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
ip6tables -A OUTPUT -m owner --uid-owner transmission -j REJECT

Order matters as much as the match. A broad acceptance earlier in the chain defeats a precise rejection later, so review the whole chain instead of appending a rule and hoping. Include both address families if the host runs IPv6, because a v4-only policy leaves a path open that nobody is watching. Keep the rules installed across restarts of both the client and the tunnel.

Decide what happens when tun0 goes away

The failure policy is the point of the exercise. If the tunnel disappears and the same hook removes the rules, the client is free to use the physical interface until something else stops it. The safe design keeps the rules and lets them reject, which is what makes the boundary independent of the tunnel's health. A teardown hook that also deletes the rules is the opposite of a failure policy.

ip link show tun0
iptables -S OUTPUT

Test it deliberately: stop the tunnel, start a transfer that is safe to abandon, and watch whether anything leaves. Then bring the tunnel back and confirm the intended path works again.

Cover the paths the rule cannot see

Name resolution may be handled by a separate resolver process, and a namespace or dedicated gateway can provide another boundary if its sharing and bootstrap paths are designed. Decide which component owns DNS and whether it follows the same egress rule. Then look at RPC: if rpc-whitelist is in use, the approved management network is part of the contract, and a broad RFC1918 range is not.

ss -tunp | grep -i transmission

Interface counters can corroborate an observation, but they cannot prove which process produced the bytes. Run a transfer you are allowed to abandon: first on the working path, then with no tunnel at startup, then through an interruption, a reconnect and a freshly created interface. Test a fresh attempt as well as a connection that was already open, because the rule may not have applied to the older socket. Record the date, the account and the result with the test.

Pasting an example that flushes the whole chain trades one hole for several, so add rules rather than clearing them. When all five checks pass, the guarantee is explicit: the client's traffic leaves through the tunnel or not at all, and the rule that enforces it survives the tunnel's own failure.

Barruulee wal qabatan