Cascading multi TOR & VPN config idea

Image Description:
– START Description –
This is a slightly altered visual taken from a SurfShark page screenshot of a HTML table doing a comparison. What I am trying to gain by a specific implementation are colored in blue boxes of which some have a sunshine sticker on them. All preferred but not mandatory are in blue boxes, all the absolute mandatory needed requirements have a sunshine sticker.

The absolute mandatory needed requirements are as follows:

:ballot_box_with_check: Your traffic is protected at Tor’s exit nodes

:ballot_box_with_check: Allows you to access sites that block Tor traffic.

:ballot_box_with_check: Doesn’t allow your Tor node host to see your real IP address.

(a text table of the unaltered image is found at: )

– END Description –

What I am trying to accomplish:
maybe by doing this chain?:question:

AppVM enforced HTTPS everywhere on browser(s) → AppVM software-firewall (maybe even a SPN here) → Qubes’ sys-net → Whonix gateway using TOR → Qubes’ sys-firewall → Qubes global OS setting for VPN1 → hardware LAN firewall 1 → hardware kill switch VPN2 → hardware kill switch canary LAN firewall 2 → dynamic IP connection out to the internet’s world wide web (the real IP Address will change every new log-on session) → TOR connection to VPN3 → VPN3 connection out to the internet’s Clearnet → Clearnet HTTPS website login portal


The reason for this self imposed insanity consideration is:
I need to log into actively targeted Google accounts of mine, which means I have to protect my IP Address as much as possible but also I must mitigate the malicious injection Zero Days risk to be possibly thrown at me upon re-touching such compromised Google account(s). I must do this eventually to complete the migration of important contacts/data from off of Google. I am aware this sounds hard to believe, but some previous Zero Days were discovered and published in January 2024 which was 1 of the Session stealers my current attacker was using. He likely has more Zero Days and I am trying not to find out the hard way again … in this Threat Model not only do I not want my attacker to find my real digital IDs such as IP Address or Session tokens but also I don’t want to sacrifice security for such anonymity either in that I must have shields remain up in defense at the “entry nodes” and “exit nodes” alike — even while still being “anonymous in an encrypted tunnel” as well as “anonymous-by-IP-Address” too; as he has malicious payloads of which may or may not have been imbedded into various Google Suite products or even spoofing certificates etc I don’t know yet the breath of all his capabilities and I don’t have the $ to keep finding out how extensively well versed across attack vectors he is

(my attacker knows my physical geographical location which means he could try to target all known local internet backbones to sniff out HTTPS traffic that he can somehow break easily, he also knows various destination websites of mine such as my banking institution’s log-in portal; thus he might be able to pick my traffic out on clearnet if I only used a VPN but with TOR and VPN(s) daisy-chained then I assume he should lose the trail from all the hops and increased layers of encryption atop of the breakable HTTPS)

Any resources within the context of
Qubes + Whonix
would be greatly appreciated

1 Like