dispVM (vpn, tor)

for testing purposes i need a dispVM which routes through

  1. sys-net
  2. sys-firewall
  3. sys-vpn
  4. sys-whonix

simply speaking: a vpn before tor entry nodes.
How should i approach? Can i simply:

  1. clone sys-whonix to sys-vpn-whonix
  2. clone whonix-ws-15-dvm to vpn-whonix-ws-15-dvm
    Or should i create a new one from scratch, for security reasons? if so, how?
    I need a dispVM only, no actual new appVM.

Thanks in advance

1 Like

As fas as i know entering Tor after your VPN is not easy to set up, as the VPN will need to handle the Tor circuits and thus have to support Tor.

Like: You are stuffing your packets in your VPN-Shell. At the VPN’s Server this is unpacked and repackaged in Tor packages. So it is not that easy as routing it through different NetVM’s as the important part is done outside of your sphere of influence.

Also i want to ask if you got a specific need for this setup, as a VPN in most common threat models makes things worse than not using it at all. Especially for your setup i don’t really see a need for, as the positive effects are minuscule and you mostly introduce failure points to the system.

If you aim for obfuscating your Tor usage agaist your ISP, maybe an anonymous VPS that you control and connect to via a VPN like wireguard or OpenVPN that then packages it into Tor.

Why is VPN(Tor()) may be not the thing you want?

  1. You have to trust your VPN. He sees everything you browse and can easily attribute it to your person. Also he could manipulate your circuits to use only “bad” relays to aid in more advanced attacks.
  2. It is a bottleneck for traffic. VPN’s should be more monitored, as many peoply “trying to hide” something using it.
  3. It is another failing point. If you (for whatever reason) trust your VPN, he could get compromised and involuntarily aid in deanonymization.
  4. More advanced Attacks should be much easier as many Tor users are expected to run this setup.

The pros:

  1. Obfuscation against the ISP or similar adversaries.

So what you could do to prevent this, is packaging your traffic in Tor on your machine and send this to the VPN to mitigate the risk.

I think, that using other means like bridges or VPS’s would be a much better choice as with bridges you don’t have to trust a single entity and don’t have a single point of failure introduced. When using a VPS it is a single point of failure, but at least it is under your control.

1 Like

Already tested this, in my testing case the VPN blocks TOR traffic and a bridge(d) connection has to be established first.

As i said for testing purposes.

A VPS is not recommended by Combining Tunnels with Tor
I claim that it is easier for people to have an anonymous VPN than an anonymous VPS (if such a thing is even possible)

Same thing for your ISP.

The bottleneck is insignificant to its security/anonymity gains. Doesn’t US/other governments run majority of TOR exit nodes?

Same goes for your suggested VPS, the data center, your ISP, etc.

1 Like