Can't connect a VPN before Tor

[nishi...@gmail.com]

Hello,

I am struggling to have VPN work while using it with Tor, I can't have both work.

I tried first to follow Mrs. Rutkowska's tutorial on setting up a clear Tor proxyVM https://theinvisiblethings.blogspot.de/2011/09/playing-with-qubes-networking-for-fun.html but unfortunately I can't make it work.

"QUBES_IP=$(xenstore-read qubes_ip)" line doesn't seem to work. If I replace "(xenstore-read qubes_ip)" with proxyVM's IP then script works but then I have to set up /etc/tor/torrc to achieve to connect Tor Browser in another AppVM. I guess this setup is too complicated for me.

Then I read whonix documentation https://www.whonix.org/wiki/Tunnels/Connecting_to_a_VPN_before_Tor, to check what I need to do to avoid reinstalling my VPN into a whonix gateway and just use it as a proxy VM before Tor.

It says you need to install a VPN firewall into the ProxyVM to avoid leaks in case your VPN connection drops but as I have already those 2 lines in "/rw/config/qubes-firewall-user-script", I don't feel I have to.
sudo iptables -t mangle -I FORWARD 1 -o eth0 -j DROP
sudo iptables -t mangle -I FORWARD 2 -i eth0 -j DROP

Overall I find quite frustrating not being able to find a clear and simple documentation on how to set up on Qubes this configuration, for those concerned about anonymity, especially when you can read on whonix document that in ~10-15 years, all those efforts to maintain your anonymity are going to be quite useless with quantum computers haha https://www.whonix.org/wiki/PQCrypto - unless you apply recommended procedures and hope Big Brothers will not unify further... :

user => VPN => Tor => internet

Which gives in Qubes something a pattern like this one below (I don't know if all firewall VMs are really needed though) :

AppVM => sys-vpn-firewall => sys-vpn => sys-whonix-firewall (or TorVM-firewall) => sys-whonix (or TorVM) => sys-firewall => sys-net

Any advices on how to set up Qubes to have a VPN + sys-whonix working together (or VPN + a TorVM proxy) in a good anonymous way would be really appreciated :)

Regards

[Chris Laprise]

On 09/08/2016 04:41 AM, nishi...@gmail.com wrote:
> Hello,
>
> I am struggling to have VPN work while using it with Tor, I can't have both work.
>
> I tried first to follow Mrs. Rutkowska's tutorial on setting up a clear Tor proxyVM https://theinvisiblethings.blogspot.de/2011/09/playing-with-qubes-networking-for-fun.html but unfortunately I can't make it work.
>
> "QUBES_IP=$(xenstore-read qubes_ip)" line doesn't seem to work. If I replace "(xenstore-read qubes_ip)" with proxyVM's IP then script works but then I have to set up /etc/tor/torrc to achieve to connect Tor Browser in another AppVM. I guess this setup is too complicated for me.
>
> Then I read whonix documentation https://www.whonix.org/wiki/Tunnels/Connecting_to_a_VPN_before_Tor, to check what I need to do to avoid reinstalling my VPN into a whonix gateway and just use it as a proxy VM before Tor.

Although its straightforward to get the opposite working (Tor -> VPN ->
Internet -- just follow the Qubes vpn doc and connect sys-whonix to the
vpn vm) there are wrinkles to iron out when getting it to work as you
describe.

Since the solution is Tor-specific, probably the best place to start is
trying create the whole setup in Whonix-Qubes using the Whonix doc you
referenced. The Whonix forum should be able to help you with any
specific issues when following their directions.

Chris

[nishi...@gmail.com]

Le samedi 10 septembre 2016 04:57:17 UTC+2, Chris Laprise a écrit :
> On 09/08/2016 04:41 AM, nishi...@gmail.com wrote:
> > Hello,
> >
> > I am struggling to have VPN work while using it with Tor, I can't have both work.
> >
> > I tried first to follow Mrs. Rutkowska's tutorial on setting up a clear Tor proxyVM https://theinvisiblethings.blogspot.de/2011/09/playing-with-qubes-networking-for-fun.html but unfortunately I can't make it work.
> >
> > "QUBES_IP=$(xenstore-read qubes_ip)" line doesn't seem to work. If I replace "(xenstore-read qubes_ip)" with proxyVM's IP then script works but then I have to set up /etc/tor/torrc to achieve to connect Tor Browser in another AppVM. I guess this setup is too complicated for me.
> >
> > Then I read whonix documentation https://www.whonix.org/wiki/Tunnels/Connecting_to_a_VPN_before_Tor, to check what I need to do to avoid reinstalling my VPN into a whonix gateway and just use it as a proxy VM before Tor.
>
> Although its straightforward to get the opposite working (Tor -> VPN ->
> Internet -- just follow the Qubes vpn doc and connect sys-whonix to the
> vpn vm) there are wrinkles to iron out when getting it to work as you
> describe.

Indeed it is easier to make it work the other way, but problem is that even if I kinda trust my VPN provider, who claims not to keep connection logs, I don't like to have my connection go through 1 spot in 1 country (you can create multiple openvpn.conf file, but this is not very convenient to use). I guess this is irrelevant to look for anonymity with this bottle neck effect. When I purchased a VPN subscription, I saw it as a way to improve anonymity, now I feel it is more a tool to provide security.

This is also why I put Tor browser as the #1 service to provide anonymity, because even if nodes exit might be observed, you still have possibilities to improve this aspect setting up bridges, besides Tor was created by the US Navy Research Laboratory, it is not a big surprise to me that the US were involved in this project. When you're talking about defense of freedom, how could one not show great admiration and love for the US. I know you have people to talk shit about US policies, that the US fucked up in Vietnam or Irak, but where would be Europe at right now if no young heroic US soldiers to sacrifice their lives to defend freedom and help beating nazi rats ? When I see rise of nationalism once again in Europe, I am just so ashamed. They don't know what's memory, what's bravery. They want another bloody tyrant on one continent in the future, they want the end of time ? Fuck this. Welcome the refugees, stop hating.

> Since the solution is Tor-specific, probably the best place to start is
> trying create the whole setup in Whonix-Qubes using the Whonix doc you
> referenced. The Whonix forum should be able to help you with any
> specific issues when following their directions.
>
> Chris

Ok thank you, I'll find out what I can do setting up Whonix. Maybe this will fix my issue https://www.whonix.org/wiki/Bridges#How_to_use_bridges_in_Whonix

[3n7r...@gmail.com]

[First, a rant. I hate mailing lists. How am I supposed to attribute quotes from earlier posts in the thread not contained in the previous post?]

nishi:

>Any advices on how to set up Qubes to have a VPN + sys-whonix working together (or VPN + a TorVM proxy) in a good anonymous way would be really appreciated :)

As you know, you can either connect to a VPN from a non-Whonix proxyVM or set up the VPN directly in the Whonix-Gateway. Both methods have the goal of preventing "unintentional" leaks and have the property of failing-closed. IMO, since you are using Qubes already, the proxyVM method is easier to configure and provides more flexibility. If you're short on RAM and/or need to operate multiple Whonix-Gateways with each having a separate VPN, you may be better off connecting to the VPN from within the Gateway. From a security/anonymity perspective, neither is obviously better than the other. A Gateway compromise would most likely be game-over in either scenario.

Speaking generally, you've got a whole bunch of moving parts. You need to troubleshoot by isolating each piece.

**This step reveals that you use Tor. Only proceed if safe to do so.

1. sys-net <- appVM: Do I have general connectivity?
2. sys-net <- vpn-VM <- appVM: Does my VPN work?
3.** sys-net <- appVM w/ Tor Browser Bundle: Does Tor work?
4.** sys-net <- whonix-gateway: Run whonixcheck. Does Whonix-Gateway work?
5. sys-net <- vpn-vm <- whonix-gateway

My suggestion is to start with a fresh proxyVM and follow Chris' Qubes VPN documentation step by step. (Or take a look at his [git repo](https://github.com/ttasket/Qubes-vpn-support) ). If the vpn-VM allows successful connections from the appVM, then it's simply a matter of assigning it to the Whonix-Gateway as its netVM. No Whonix-specific configuration is necessary since it's all transparent to Whonix.

* Make sure that the Qubes firewall (Qubes VM Manager) is open on the Whonix-Gateway. I don't remember what the default setting is.

* Both TCP and UDP are fine for upstream VPNs. Tor can not carry UDP but it can be carried on UDP, if that makes sense.

* Don't add any additional firewalls until you can get this working.

nishi:

>Which gives in Qubes something a pattern like this one below (I don't know if all firewall VMs are really needed though) :
>
>AppVM => sys-vpn-firewall => sys-vpn => sys-whonix-firewall (or TorVM-firewall) => sys-whonix (or TorVM) => sys-firewall => sys-net

Firewalls have limited usefulness as described here: https://www.qubes-os.org/doc/data-leaks/

rustybird's Corridor can ensure that all traffic goes to a Tor Entry Guard (but obviously, can't guarantee that the Entry Guard is trustworthy).

nishi:

>When I purchased a VPN subscription, I saw it as a way to improve anonymity, now I feel it is more a tool to provide security.

VPNs don't necessarily improve anonymity OR security. They simply shift the trust that you place in your ISP to someone else. That may be good or bad.

Chris:

>Although its straightforward to get the opposite working (Tor -> VPN ->
Internet -- just follow the Qubes vpn doc and connect sys-whonix to the
vpn vm)

Just to clarify, to achieve user -> Tor -> VPN -> Internet, sys-whonix needs to be connected as the *netVM* for the vpn-vm. If vpn-vm is the netVM for sys-whonix, the resulting traffic is user -> VPN -> Tor -> Internet. I may be forgetting something, but I believe both configurations work out of the box.

[nishi...@gmail.com]

Hello,

Thank you for your answer. Yes I agree with you, the proxyVM is easier to configure and provide more flexibility. I don't know if you can make your VPN autostart if you install it inside the whonix gateway, so I rather prefer to have it directly installed in an AppVM, because I find it is a great Qubes feature : )

Also as I said directly in the Whonix-forum site, I don't believe building a fortress in a gateway that will become the main target for hackers is what will necessarily will make us all more secure out there. Whonix or Qubes are targets right now... You have too many hacking intrusion exploits nowadays to build a fail-safe system for everyone. If you just type list in metasploit on kali Linux you know what I mean... I feel like people working on Whonix would be a really more usefull to random noobs like me and most of the internet community by trying to act like hackers, idea being to create a code able to send back nukes to people entering your own private space. I see global improvement of internet security this way. Btw Qubes is born on this idea (the "blue pill" attack), and even it is probably one of the most secured OS out there atm, I wish you would have OS able to react to attacks by sending back the attack or to create a new one, to tell hackers "heeeeey leave me alone dude, ur gonna get nuked in return, don't waste your time :d" lol. But that's just a personal opinion and I am probably too naive on complexity required to make this happen one day...

Thanks again for all your explanations. To answer your questions :
1. sys-net <- appVM: Do I have general connectivity? Yes
2. sys-net <- vpn-VM <- appVM: Does my VPN work? Yes
3.** sys-net <- appVM w/ Tor Browser Bundle: Does Tor work? Yes
4.** sys-net <- whonix-gateway: Run whonixcheck. Does Whonix-Gateway work? Yes
5. sys-net <- vpn-vm <- whonix-gateway Yes

In fact my only problem is that I need to run my VPN in TCP to have a connection with sys-whonix. It doesn't work in UDP in a user -> VPN -> Tor scheme and also in the other way always in UDP.
UDP is a bit faster than TCP but less secured, I don't really know if I should use either UDP or TCP just to browse the web.

Tanks a lot for sharing rustybird's Corridor, it looks like a very interesting program for people concerned about security on Tor https://github.com/rustybird/corridor
It looks a bit complicated to set it up on Qubes but I am gonna try it !

If you could explain to me how I could add firewalls between proxyVMs, that would help me. What I could go for is a scheme like this (on a user -> VPN -> Tor -> internet connection) :
sys-net <- sys-firewall <- sys-whonix <- sys-firewall2 <- sys-vpn <- sys-firewall3 <- AppVM.

I would probably allow all traffic on all the firewalls because Andrew David Wong who works a a community manager on Qubes told me here that it doesn't matter, you have to set up rules only after the proxys directly on the AppVM (or the next proxyVM). I am probably stupid or paranoid to add all those proxyVMs, I have no good idea bout what I'm doing, just playing with Qubes legos ^.^

https://www.whonix.org/wiki/Stream_Isolation I tried to open ports 9150, 9110 and 9051 on the tcp protocl sys-whonix to reduce a bit the surface attack, but it didn't work. So I am gonna let it all opened but on the sys-vpn it seems to connect if I put a rule like accepting all the IP adresses only on the gateway port inside my openvpn client file : )

For the AppVM, I deny all traffic, I just add an exception to open http / https port for all adresses. And even if it worked during my tests without all the firewallVMs, I have an IP adress provided by my VPN if I google "ip address", which looks logic as I am connected first to the sys-vpn, which then connect to the TorVM. My IP should be probably different at the outside of the sys-whonix. But if I'm wrong and I have to run whonix-workstation or TBB installed into the AppVM, please tell me, I am a bit confused about this situation :v

[3n7r...@gmail.com]

Both Whonix and Tor work fine over UDP. This is most likely a VPN-specific configuration issue. Your provider may have different ports and/or ciphers for TCP vs UDP.

Conventional wisdom would argue against TCP over TCP over TCP. However, given Tor's already massive latency and slow connections, it's hard to say whether you'd even notice a difference between VPN over TCP vs UDP.

> Tanks a lot for sharing rustybird's Corridor, it looks like a very interesting program for people concerned about security on Tor https://github.com/rustybird/corridor
> It looks a bit complicated to set it up on Qubes but I am gonna try it !
>
> If you could explain to me how I could add firewalls between proxyVMs, that would help me. What I could go for is a scheme like this (on a user -> VPN -> Tor -> internet connection) :
> sys-net <- sys-firewall <- sys-whonix <- sys-firewall2 <- sys-vpn <- sys-firewall3 <- AppVM.
>

First of all, that VM configuration will result in user -> tor -> vpn so make sure you've got that right.

You can add explicit firewall VMs wherever you want or you can configure firewall rules using Qubes VM Manager.

Whether or not that makes any sense is a different discussion. As stated previously, firewalls contain "inadvertent leaks", not "intentional leaks". ( https://www.qubes-os.org/doc/data-leaks/ ) The main purpose of a firewall is to block upstream traffic. So the consensus location for a firewall would be just inside sys-net. If sys-whonix is connected directly to sys-net, it already has a restrictive firewall and doesn't really need another.

> I would probably allow all traffic on all the firewalls because Andrew David Wong who works a a community manager on Qubes told me here that it doesn't matter, you have to set up rules only after the proxys directly on the AppVM (or the next proxyVM). I am probably stupid or paranoid to add all those proxyVMs, I have no good idea bout what I'm doing, just playing with Qubes legos ^.^
>
> https://www.whonix.org/wiki/Stream_Isolation I tried to open ports 9150, 9110 and 9051 on the tcp protocl sys-whonix to reduce a bit the surface attack, but it didn't work. So I am gonna let it all opened but on the sys-vpn it seems to connect if I put a rule like accepting all the IP adresses only on the gateway port inside my openvpn client file : )
>

[Whonix specific questions are probably better asked on Whonix.org, since 1. that's where Patrick lives, and 2. that's where people will go to find answers to Whonix questions.]

I don't understand your question. You opened ports where? Stream Isolation is in effect by default. It means that a pre-configured application running in Whonix-Workstation, like Tor Browser, sends its traffic to a specific port on Whonix-Gateway's inward-facing network adapter. Whonix-Gateway then routes the traffic over a new Tor circuit. No ports need to be opened **or closed** because following the same reasoning with firewalls/leaks, a compromised Workstation could just switch traffic to an open port.

I'm assuming here that you mean to route your traffic: user -> vpn -> tor. If in fact, you have your VM's setup like sys-net -> sys-whonix -> sys-vpn -> appVM, then no, stream isolation is not possible. And this is precisely why I stated that user -> tor -> vpn reduces anonymity. Your vpn connection, and everything going through it will travel over 1 tor circuit for its active lifetime unless a relay goes offline.

> For the AppVM, I deny all traffic, I just add an exception to open http / https port for all adresses. And even if it worked during my tests without all the firewallVMs, I have an IP adress provided by my VPN if I google "ip address", which looks logic as I am connected first to the sys-vpn, which then connect to the TorVM. My IP should be probably different at the outside of the sys-whonix. But if I'm wrong and I have to run whonix-workstation or TBB installed into the AppVM, please tell me, I am a bit confused about this situation :v

Again, denying all traffic except http/https just means that malware will communicate over 80/443, which any decent malware should do anyway.

The reason why google is showing you your vpn ip address is because your traffic is flowing: user -> isp -> tor -> vpn -> destination (google)

[nishi...@gmail.com]

Yes indeed, I figured out I have an address resolving problem by trying to connect manually to my VPN instead of using the rc.local script from the documentation https://www.qubes-os.org/doc/vpn/ with this command :
sudo openvpn --writepid /var/run/openvpn/openvpn-client.pid --cd /rw/config/openvpn/ --config openvpn.ovpn
It cannot resolve host adress, but after 2 mn... my VPN works xd

I thought latency on connection was created by the fact I am spoofing my MAC adress, but I was wrong https://www.qubes-os.org/doc/anonymizing-your-mac-address/

I followed this line : # To override DHCP DNS, assign static DNS addresses with 'setenv vpn_dns' in openvpn config;
# Format is 'X.X.X.X Y.Y.Y.Y [...]' with quotes.
by adding in my openvpn.ovpn conf file this line but unfortunately it doesn't seem to work well (I have to kill my sys-vpn to shut down the connection) :
setenv vpn_dpns 'X.X.X.X X.X.X.X' (dns adress of my VPN provider)

If you could help me on this problem as well, that would be really great. Thanks again for your concern, I really appreciate and I hope that it might help others people struggling with their own VPNs.

In fact at first I followed this great guide done by cprise https://groups.google.com/forum/#!topic/qubes-users/-9gR1Va3BnY, I had no IP resolving problem, then I switched to official documentation because I wasn't sure with only those 2 lines added in /rw/config/qubes-firewall-user-script, I would be safe if my VPN would drop on a "sensitive" website. And let's be clear by what I called "sensitive" here : by "sensitive" I just mean that I don't really give a damn that my ISP is actually knowing that I go on some websites that criticize politics here in my country (like this one : https://la-bas.org/ ), as they're legal, but of course I don't want my ISP to actually know what content I'm reading there.

>
> > Tanks a lot for sharing rustybird's Corridor, it looks like a very interesting program for people concerned about security on Tor https://github.com/rustybird/corridor
> > It looks a bit complicated to set it up on Qubes but I am gonna try it !
> >
> > If you could explain to me how I could add firewalls between proxyVMs, that would help me. What I could go for is a scheme like this (on a user -> VPN -> Tor -> internet connection) :
> > sys-net <- sys-firewall <- sys-whonix <- sys-firewall2 <- sys-vpn <- sys-firewall3 <- AppVM.
> >
>
> First of all, that VM configuration will result in user -> tor -> vpn so make sure you've got that right.
>

OMG. I am completely confused right now about OSI model and the terminology you use. Please give me a link please so I can get what we're talking about, because I don't understand a thing about it. All I know is that OSI model goes this way : internet -> applications. And based on that, I can't understand what you said, because I have no idea what's is the precise difference between selecting a NetVM in a ProxyVM or data flowing with the arrow oriented terminology you used xd

I mean you could understand user -> Tor -> VPN -> internet is : I pick sys-whonix as NetVM for my VPN, but you could understand as well were are here in the OSI model and that would mean here that you pick your sys-net as a NetVM into your sys-vpn VM, which is the opposite.

Im am a complete newbie, and indeed I acknowledge I was wrong to make simplifications over 2 very complex projets (just look at this page : https://www.whonix.org/wiki/Comparison_with_Others , if you're not an engineer, hf to make a good choice there, lol).
But still, making it harder to understand that it is already is not gonna make things easier for me :(
I noticed you said "Just to clarify, to achieve user -> Tor -> VPN -> Internet, sys-whonix needs to be connected as the *netVM* for the vpn-vm" and I appreciate your comment, but it doesn't clarify a lot if you use after arrows in the reverse order. I'm lost ;_;

> You can add explicit firewall VMs wherever you want or you can configure firewall rules using Qubes VM Manager.
>

Yes that what I'm doing right now, I use Qubes manager : )

> Whether or not that makes any sense is a different discussion. As stated previously, firewalls contain "inadvertent leaks", not "intentional leaks". ( https://www.qubes-os.org/doc/data-leaks/ ) The main purpose of a firewall is to block upstream traffic. So the consensus location for a firewall would be just inside sys-net. If sys-whonix is connected directly to sys-net, it already has a restrictive firewall and doesn't really need another.
>

I understand better. Thank you very much for this explanation, this is clearer to me now. Ok so then you can think about Firewalls in Qubes manager as a way to avoid parts of the traffic routed from an upstream interface to your VM. To block ports inside this VM coming from this traffic, you have then to do it inside with iptables. That makes sense :)

>
> > I would probably allow all traffic on all the firewalls because Andrew David Wong who works a a community manager on Qubes told me here that it doesn't matter, you have to set up rules only after the proxys directly on the AppVM (or the next proxyVM). I am probably stupid or paranoid to add all those proxyVMs, I have no good idea bout what I'm doing, just playing with Qubes legos ^.^
> >
> > https://www.whonix.org/wiki/Stream_Isolation I tried to open ports 9150, 9110 and 9051 on the tcp protocl sys-whonix to reduce a bit the surface attack, but it didn't work. So I am gonna let it all opened but on the sys-vpn it seems to connect if I put a rule like accepting all the IP adresses only on the gateway port inside my openvpn client file : )
> >
>
> [Whonix specific questions are probably better asked on Whonix.org, since 1. that's where Patrick lives, and 2. that's where people will go to find answers to Whonix questions.]
>
> I don't understand your question. You opened ports where? Stream Isolation is in effect by default. It means that a pre-configured application running in Whonix-Workstation, like Tor Browser, sends its traffic to a specific port on Whonix-Gateway's inward-facing network adapter. Whonix-Gateway then routes the traffic over a new Tor circuit. No ports need to be opened **or closed** because following the same reasoning with firewalls/leaks, a compromised Workstation could just switch traffic to an open port.
>

I was trying to understand if you necessarily need firewalls (using Qubes manager) between each proxyVM, or if you can just have 1 at the connection input (so before sys-net, in this order sys-net -> sys-firewall), which will filter both input and output. I'm just a retarded newbie, you know.

So my question was I don't understand that let's say if you apply iptables rules in a proxy using /rw/config/qubes-firewall-user-script (as documentation says it needs to be there because firewall constantly refresh on proxies, whereas on normal AppVM you can put them in rc.local on startup), what do you really need to do to make it work using in combination firewall in Qubes manager.

What I'm confused about is that if you want to redirect traffic to another AppVM, you are supposed to it directly inside the concerned VM using nat, this I can understand, but then you if you deny all traffic in the destination VM using the Qubes manager, you just have to add an exception traffic only for the service and the port used, is that right ?

I would appreciate that Qubes documentation contains something to explain better to noobs or retards like me (lol) how VMs communicate each others and how to use Qubes firewall to add exceptions to deny traffic for a specific VM.

I know few on gateways, for instance I know let's your VM IP is X.X.2.18 and your sys-firewall IP is X.X.3.12, I know that if you want your VM IP to allow a service like SSH listening on port 22 bypassing the firewall, you are always gonna go through your own gateway (X.X.2.1) to reach other local computer, and then the gateway routes traffic, but as traffic between VMs looks blocked by default for security reasons, it makes it really complicated to understand how nat works
https://www.qubes-os.org/doc/qubes-firewall/

But I just read man iptables, and it seems nat is used on Qubes all the times to make sure sys-net packets aren't blocked and can go through the chains, like on this script :
"iptables -t nat -F PR-QBS
if [[ -n "$vpn_dns" ]] ; then
# Set DNS address translation in firewall:
for addr in $vpn_dns; do
iptables -t nat -A PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to $addr
iptables -t nat -A PR-QBS -i vif+ -p tcp --dport 53 -j DNAT --to $addr "

What I get here is you got this traffic coming from your vif bridge and is it blocked by default, but then if your DNS resolver in the openvpn file matches to the adress option, your firewall jumps to a DNAT rule, which is chinese to me xd haha.

> I'm assuming here that you mean to route your traffic: user -> vpn -> tor. If in fact, you have your VM's setup like sys-net -> sys-whonix -> sys-vpn -> appVM, then no, stream isolation is not possible. And this is precisely why I stated that user -> tor -> vpn reduces anonymity. Your vpn connection, and everything going through it will travel over 1 tor circuit for its active lifetime unless a relay goes offline.
>

No offense, but why would you assume a fact that is clear coming from me since the very beginning ? I am trying indeed to connect to Tor from my VPN IP address. I don't know how to write it like you do so that in your AppVM you just have a Tor IP address that have been through your own VPN if you type "what's my ip" on Google. What I get about the way your write this connection model is that you reverse the order. Probably because the OSI model goes only from internet to applications. But still, I don't really understand very well the logic behind.

I didn't know that on user -> tor -> vpn configuration, Tor will route traffic into 1 tor circuit only for it's active lifetime (do you mean it will bypass every 10 mn refresh node changing on standard TBB because of the VPN ?), but I do know that your exit connection will not be encrypted on this configuration, whereas it is encrypted with only a VPN connected w/o Tor, or if you use it in the reverse order. I'm just trying to configure this set-up, it doesn't mean that I approve or disapprove it.

I think I kinda agreed with you in a way when you stated "user -> tor -> vpn reduces anonymity". On Whonix site, I was thinking this configuration would increase security, but at the cost of reducing anonymity. I was just thinking in the opposite way, not understanding a shit, lmfao.
Anyway I don't necessarily think it is a good way to use a VPN before Tor and to tell your VPN provider that's you're doing so... Whether you trust him or not.
Whatever. As I told you, I am completely confused about the terminology you used. My idea on Whonix site was just simply that I rather prefer the idea not having my connection going unencrypted through one narrow tunnel that could be observed, and it might looks strange, but that's what I want to experiment right now, to test it out (a VPN before Tor). Even if it is less anonymous, I don't care, just trying things.

So I kinda agree with you that I would prefer the other configuration for anonymity reasons : user -> vpn -> tor, so if I'm not completely braindead right now, it would look like this (just delete the topic if I'm wrong I'll kill myself anyway lmao xd) : sys-net -> sys-vpn -> sys-whonix -> appVM, so you pick sys-vpn as a netVM for sys-whonix and you ends up with a TOR ip adress.

>
> > For the AppVM, I deny all traffic, I just add an exception to open http / https port for all adresses. And even if it worked during my tests without all the firewallVMs, I have an IP adress provided by my VPN if I google "ip address", which looks logic as I am connected first to the sys-vpn, which then connect to the TorVM. My IP should be probably different at the outside of the sys-whonix. But if I'm wrong and I have to run whonix-workstation or TBB installed into the AppVM, please tell me, I am a bit confused about this situation :v
>
> Again, denying all traffic except http/https just means that malware will communicate over 80/443, which any decent malware should do anyway.
>
> The reason why google is showing you your vpn ip address is because your traffic is flowing: user -> isp -> tor -> vpn -> destination (google)

Ok, thank you. So I'll just configure directly iptables into the AppVM, using -P INPUT DROP and then adding every service that I want to use, hoping default firewall Qubes firewall is not gonna give me too much trouble lol