VPN KILLSWITCH & Parallel traffic

KVM
1

Greetings to all you guys and also Whonix ™ KVM Maintainer!

My topic is specific to this connection method: User → VPN → Tor → Internet

It all started with the need for VPN ----> Whonix (Gateway) to hide the fact of using the TOR from the ISP.

I began to look for a solution, and found out that with such a connection scheme as VPN----->WHONIX (Gateway), the traffic goes not consistently, but in parallel way! As a result, Tor traffic is not encapsulated in VPN. And there is a leak.

I have a few questions:

  1. Can I create an additional virtual machine that will act as VPN-Gateway which then will be connected to Whonix-Gateway? Thus, the traffic will be consistent(But in this case, you will have to change the connection with NAT to the isolated network in Whonix -gateway, which can be discouraged and can make leaks );

https://www.whonix.org/wiki/Tunnels/Connecting_to_a_VPN_before_Tor#KVM_VPN_Killswitch

> <network>
>   <name>Whonix-External</name>
>   <forward dev='tun0' mode='nat'/>
>   <bridge name='virbr1' stp='on' delay='0'/>
>   <ip address='10.0.2.2' netmask='255.255.255.0'>
>   </ip>
> </network>

This method of the VPN-killswitch was presented in official article. The question is how much this method is reliable from leaks and this method does consistent connection or parallel?

Either configure VPN-Router, or make VPN Tethering Via Android Device. In order not to discount the Whonix settings. Since I believe that digging in the settings of Whonix Firewall or other configs can easily be broken something, especially if you don’t know how does unix routing works.

  1. What method of connection according to my requirements is more optimal and reliable, perhaps which I do not know?

As I understand a lot of people do this way and this is stupidity, because they think that traffic is a consistent.

I would like to hear the detailed answers. Thanks to everyone!

1 Like
2

Before combining Tor with other tunnels, be sure to read and understand the risks!

  • It is not simple to configure VPNs, SSH or proxies in a foolproof, leak-free manner. However, in the case of Whonix it is impossible for traffic to bypass Tor, even if the VPN or proxy is misconfigured. [26]

It’s a challenging setup, and I appreciate the detailed questions and the effort you’ve already put into researching this.

To address the broader issue of setting up User → VPN → Tor → Internet securely and reliably: this configuration requires deep technical expertise in networking, virtual machines, and security principles. While it is possible to achieve, implementing this correctly without leaks and ensuring reliability is not a straightforward task.

Thank you again for raising this discussion. Your curiosity and initiative are admirable, and I hope this perspective helps clarify the challenges and potential solutions.

1 Like
3

The easiest way to streamline tor connections with tight firewall rules in mind, is to use the torrc config option ReachableAddresses and have tor connect via a specific port or address, for example: ReachableAddresses *:443 @ port 443.

Then you just create iptables rules for that port, preferably with a conntrack ESTABLISHED on the INPUT rule and default drop policy on OUTPUT.
That’s the killswitch, only specifically allowing your designated traffic and dropping everything else by default.

Depending on the network, you’ll most likely be using FORWARD, though.

If you’re still interested in this I can give you some more detailed instructions.

4

Seems to be under the assumption that Tor honors that.

Might be so but also might not be so.

Reason for to verify that assumption:

Tor will make still certain network-related calls (like DNS lookups) even if DisableNetwork is set. Quote Tor man page:

DisableNetwork 0|1 When this option is set, we don’t listen for or accept any connections other than controller connections, and we close (and don’t reattempt) any outbound connections. Controllers sometimes use this option to avoid using the network until Tor is fully configured. Tor will make still certain network-related calls (like DNS lookups) as a part of its configuration process, even if DisableNetwork is set.

1 Like
5

Tor will make still certain network-related calls (like DNS lookups) as a part of its configuration process, even if DisableNetwork is set.

I did not know this.

Here’s a basic setup with VPN on host:

Nat with VPN dev:

<network>
  <name>Whonix-External</name>
  <uuid>09200d9b-ac7f-48f4-bb31-fc5dc3f3ce3e</uuid>
  <forward mode='nat' dev='tun0'/>
  <bridge name='virbr1' stp='on' delay='0'/>
  <mac address='12:46:00:32:6f:2c'/>
  <ip address='10.0.2.2' netmask='255.255.255.0'/>
</network>

Only allow specific port from VM:

$IPTABLES -P FORWARD DROP

$IPTABLES -A LIBVIRT_FORWARD_IN -d 10.0.2.0/24 -p tcp -m tcp --sport 443 -i "$VPN_DEV" -o virbr1 -m conntrack --ctstate ESTABLISHED -j ACCEPT

$IPTABLES -A LIBVIRT_FORWARD_OUT -s 10.0.2.0/24 -p tcp -m tcp --dport 443 -i virbr1 -o "$VPN_DEV" -j ACCEPT

If the VPN (tun0) drops, nothing should get through.

But with tun0 up, if TOR initiates the connection via port 443, then sure. I guess you could make the rule more specific with --tcp-flags SYN,ACK SYN,ACK ?

6

The only leak-resistant way is to filter by network interface, by VM or by Linux user name.

iptables is deprecated.

7

The only leak-resistant way is to filter by network interface by VM or by Linux user name.

Yeah, this would be by interface, but iptables is very old, of course.
Libvirt uses them natively and creates those chains automatically (Or maybe now only with firewall_backend = "iptables" in network.conf). And with/etc/libvirt/hooks/network custom rules can be inserted / removed when the network starts and stops.

I know that you have a repo called vpn-firewall. That’s probably a more elegant solution. OP should have a look at that too.