I need to implement a Tor → VPN traffic flow on Qubes OS 4.3 with Whonix 18 in the following order:
User AppVM → sys-whonix (Gateway) → sys-vpn (WireGuard, Mullvad or Proton VPN) → sys-firewall → sys-net
Threat model: State-level Deep Packet Inspection (DPI) where even WebTunnel bridges are quickly detected and blocked. I understand VPNs are not generally recommended for hiding Tor usage from a local adversary, but standard obfs4 traffic remains fingerprintable here.
Required modifications to sys-whonix (per Whonix docs):
Disable Stream Isolation – add uwtwrapper_global=“0” to /etc/uwt.d/50_user.conf
Trade-off: weakens anonymity (correlation between activities), but forces all traffic (including Tor Browser) through the VPN tunnel.
Modify arp_ignore – change net.ipv4.conf.all.arp_ignore from 2 to 1
Reason: allows connectivity to the sys-vpn gateway; otherwise the connection stalls.
Primary goal: Make all traffic from my Qubes OS system blend in as ordinary encrypted VPN traffic (WireGuard), removing distinctive obfs4 patterns.
Secondary goal (new): Hide the fact that I am using Qubes OS itself. I understand Qubes may have detectable traffic patterns (e.g., NTP requests from multiple VMs, update checks, VM-to-VM timing patterns). Will the Tor → VPN setup above obscure these fingerprints, or are additional steps required?
Specific technical questions
Effectiveness against DPI
· Will the internal Tor cell structure (fixed 512/514-byte cells) still be visible inside WireGuard encapsulation, leaving a detectable fingerprint?
· If yes, are there any methods at the sys-vpn level (e.g., random padding, traffic shaping) to mask the cell pattern?
Verifying no bypass after disabling Stream Isolation
· How can I confirm that no application inside sys-whonix or downstream AppVMs is inadvertently bypassing the forced VPN route?
· Is a default-deny firewall on sys-vpn (allowing only the VPN server IP:port) plus tcpdump monitoring sufficient?
Partial stream isolation at sys-vpn level
· What practical methods can re-establish some stream isolation at the sys-vpn level to mitigate identity correlation risk?
· Examples: multiple sys-vpn instances (different WireGuard peers), or nftables rules routing different source IPs through different tunnels?
Hiding Qubes OS fingerprints (new)
· What specific configuration changes are needed to prevent Qubes OS from being identified via:
· NTP requests from each VM?
· Update checks (Fedora/Qubes repositories)?
· TCP/IP stack fingerprinting?
· Any VM-to-VM traffic patterns visible at the sys-net level?
· Would routing all VMs through sys-whonix (as ClockVM and UpdateVM) be enough, or are additional sysctl/nftables tweaks required?
Environment:
· Qubes OS 4.3
· Whonix 18 (Debian 13)
· VPN provider: either Mullvad or Proton VPN (WireGuard protocol)
· sys-vpn is a dedicated ProxyVM with three-layer kill switch (as in community guides)
· sys-whonix NetVM = sys-vpn
ISP will see a traffic pattern (count bytes over time), no much matter with or without VPN. TOR tries to add noise but in real it is not enough for protect you from tracing by traffic flow. In your case WireGuard use a encapsulation and transalte any traffic type to server into UDP like traffic. If TOR bridges in reality blocked in your country you would like to try another DPI resistant solution instead of WG, like a AmneziaWG. You could try to use noise like traffic generation, but I didn’t tried to do that, so I’m not sure.
I’m not sure about your choice, so IMO you need to configure a sys-vpn qube, u can use qvm-firewall cli, for disable ICMP and DNS. It should works with default whonix contiguration, at least that worked well a couple years ago. Just try to configure a whitelist in your sys-vpn for avoid leaks. Qubes firewall works well, but you can verify it in upstream netvm, for example in sys-firewall with wireshark/tcpdump etc.
Advanced DPI can identify Tor behind a VPN, but now we are talking about a state level targeted surveillance with Packet Size and Inter-Arrival Timing, Entropy Analysis etc.
Not your garden variety mass surveillance.
If you’ve been blocked using the Tor → VPN setup (and the NSA is not after you), it’s probably due to the VPN server, not TOR.
I think what you are doing is hurting your anonymity rather than helping it.
As far as hiding the use of Qubes, why not just do updates through Tor?
If you can connect to a VPN through it, you can download updates too.
It’s not like ‘they’ will target you because they see someone (amongst many users) updating multiple distros at the same time over Tor. I don’t think this should be a concern.
Just to clarify, this is a purely technical discussion. I haven’t been blocked myself; I’m exploring theoretical limits for a hostile environment.
You raise fair points about the flaws of a standard Tor → VPN setup, specifically regarding Tor’s fixed cell structure and packet timing being vulnerable to advanced DPI. Thank you for that.
However, you didn’t offer a practical alternative. So, let me ask you this:
If the core issue is WireGuard’s predictable signatures, what is your take on using AmneziaWG in the sys-vpn? It is a fork designed specifically to counter DPI by randomizing packet sizes and dynamically changing headers to mimic legitimate UDP traffic. This seems to address the exact fingerprinting concerns you mentioned.
Would implementing AmneziaWG between sys-whonix and the internet make Tor → VPN a more viable setup, or are there other fundamental flaws you see?
AmneziaWG is just another VPN provider with some good obfuscation capabilities, like other VPN providers, like the ones you mentioned, Mullvad, Proton and so forth. They offer multiple hops, AI protection (whatever the hell that is) and generally they do data padding in combination with mixing you with several users on their servers.
All that is great, but the problem is trust. I don’t trust any of those VPN providers and I don’t use them on their own. I always route through multiple providers (and/or Tor).
Even the ‘super private’ ones (Mullvad & Proton) will be vulnerable to monitoring from nation states (or they could just be honeypots).
Routing through VPNs and Tor, in my opinion, pretty much eliminates DPI, unless you are specifically targeted with a lot of resources and time.
EDIT. Even downloading torrents in the background through the VPN, in a tor → vpn setup, would help with DPI by introducing a lot of noise, lowering the SNR. These tracking techniques are probabilistic.
Thank you for raising this point. I fully agree that trusting a VPN provider is a real problem. However, there is a fundamental distinction: AmneziaWG is not a “VPN provider” like Mullvad or Proton. It is an open-source protocol (a fork of WireGuard) that you can self-host on your own private VPS, paying for it with Monero without leaving any identity behind. This way, you don’t trust any VPN company (neither Amnezia nor others). You only trust the hosting provider – a risk that can be mitigated by choosing a provider outside your adversary’s jurisdiction.
Regarding how to practically implement this setup on Qubes OS, there is a detailed community guide on the forum (not official from Whonix or Qubes, but practical and trusted by users):
In short: AWG protocol + private VPS + Tor + disabling stream isolation is currently the best available solution against advanced DPI.
That would be a good setup, but it’s not JUST meant to beat DPI. That’s already accomplished (again, in my opinion) by stringing vpn and TOR together.
Yes, you still have to trust the VPS hosting provider. In which case you can just install any other VPN provider with all their obfuscation tricks.
Let me share my ultra paranoid network setup with you. sys-net → sys-firewall → sys-vpn → whonix (tor) → VPS (self-host AmneziaWG)
All your DPI problems are solved by the time you exit TOR.
The VPN and VPS providers have to be from different “spheres of global influence”. Basically if your VPN is from western providers, get a VPS in China, or Russia (pay for both with Monero, goes with out saying).
AmneziaWG in the vps only makes sense to escape Russian/Chinese censorship and get you back to the open internet.
With this setup you can probably tell world leaders directly to go fuck themselves and you won’t be tracked, if done right.
EDIT. If you put the vps after tor, you don’t need to change any whonix settings that weakens anonymity and you are able to use that network qube for other traffic safely.
Yes, if you are in those countries and want to bypass restrictions, using amnesiaVPN by itself makes sense. No need to pass traffic through other servers though.
Disabling stream isolation is required if the VPN acts as the exit node, as in the following setup:
AppVM → sys-vpn → sys-whonix → internet
However, if the AppVM communicates directly with sys-whonix and sys-whonix connects to the internet via VPN, you should not disable stream isolation. There is no need for it in this configuration, and doing so would significantly decrease anonymity.
Thank you for the link. I read the official Whonix page you sent.
It clearly says:
“Disabling stream isolation will prevent bypassing of the tunnel-link. Applications configured to use Tor SocksPorts are not tunneled through the tunnel-link – they only go through Tor.”
The solution given by Whonix is:
Disable stream isolation (uwtwrapper_global=“0”).
This applies to my setup:
AppVM → sys-whonix → sys-vpn (Tor before VPN)
Your setup is different:
AppVM → sys-vpn → sys-whonix (VPN before Tor)
In your case, disabling stream isolation is not needed.
In my case, the official Whonix documentation says it is required.
We are both correct – just different configurations.
Well, I’m not sure if it’s due to a language barrier or something else, but either you misunderstood me, or I misunderstood you.
In the following setup: AppVM → sys-vpn → sys-whonix → internet
Disabling stream isolation is necessary because applications configured to use stream isolation cannot communicate directly with sys-whonix. Therefore, you must disable it.
In contrast, in this setup: AppVM → sys-whonix → sys-vpn → internet
The AppVM can communicate directly with sys-whonix, so there is no need to disable stream isolation.
Amnezia WG can be user on any VPS. Just do a bit research about VPS provides.
I’ve never tried awg-quick. For configuration just check guide below. For firewall configuration you can use qvm-firewall. Default amneziaWG port is 51820/UDP
I’m not sure but probably step with uwtwrapper_global="0" is not required to make it work. But you need to test it self.
Right, I need to update my curated hosting directory for June, but here is the relevant URL for the specified criteria, assuming Tor Browser only usage set to Safest:
To be super brief, I will be deduplicating and folding the Whonix Forum topic, the Whonix Wiki page, kycnot.me, bitcoin-vps.com and the Tor Project’s Good Bad ISPs page into the hosting directory:
Ignore the rest of the post in the Whonix Forum, my other public activities are irrelevant for Qubes OS and this topic.
I started an initial trial: using ProtonVPN instead of AmneziaWG, then making it automatically connect to a specific server on startup, as well as configuring the qvm-firewall to that server’s IP to act as a kill switch. I found no issues with these settings.
Specific technical questions