Preventing non-Tor connections

User Support
1

Until document how to route all traffic over Tor / how to disable Qubes default clearnet traffic · Issue #7586 · QubesOS/qubes-issues · GitHub is resolved Qubes users require a way of ensuring no non-Tor connections are made when they are working over Tor.

My current solution is to only have open the following qubes
anon-whonix → sys-whonix → sys-firewall → sys-net

And have the following firewall rules in sys-firewall and sys-net

sudo nft add chain ip filter OUTPUT ‘{ policy drop; }’
sudo nft add rule ip filter OUTPUT counter drop

sudo nft add chain ip6 filter OUTPUT ‘{ policy drop; }’
sudo nft add rule ip6 filter OUTPUT counter drop

These rules are added before sys-net is connected to any network.

Can anyone identify any issues with this?

I should add that this is done in addition to disabling update checking and making sure sys-net is not used as UpdatesProxy.

2

Why is this part necessary?

3

As it says in the linked GitHub issue nobody has documented what clearnet traffic is generated by the various VMs, at least not extensively.

When you are connecting to Tor, especially when moving between different networks, you do not want any clearnet connections to be made.

The firewall rules prevent any clearnet traffic other than DHCP which uses raw sockets so bypasses netfilter.

4

Read more about corridor here: Using corridor, a Tor traffic whitelisting gateway with Whonix ™

5

Well, it doesn’t look like what is said in the original link

It is possible to configure Whonix-Gateway ™ ( sys-whonix ) to use corridor as a local proxy to establish the following tunnel:
User → corridor → Tor → Internet

6

You should read the entire page:

Configure sys-whonix
To set Networking of sys-whonix to sys-corridor :

Qube Manager → left-click sys-whonix → right-click → Qube settings → Networking → sys-corridor → OK

The procedure is now complete.

1 Like
7

Thanks! I Started to read and trying to install corridor, so didn’t reach the point. Anyway, there is inconsistency on that page anyway right?

8

The bit you quoted could be explained better, I agree.

Also, it may be useful to know that you don’t have to create it as a standalone. I got it working as a non-persistent qube (just create a template instead of a standalone, then a dispvm template and finally an appvm based on that).

1 Like
9

Well, I wouldn’t say “better”, but correct. Anyway…

Yes, it looked odd to me to create a standalone for anything that is service… And I couldn’t install it based on minimal (standalone based on minimal)

So, if I’m not using tor bridges, it should work immediately after install?

10

Probably just missing a few packages

Yes, most likely

11

Thanks. I’m not sure what’s with other prefs and features. like provides_network, etc…
What’s netVM of corridor? sys-firewall?

12

Nope. Forwarding and snat not working

forwarding 
user@sys-corridor:~$ sudo systemctl --no-pager status corridor-init-forwarding
��� corridor-init-forwarding.service - corridor's forwarding
     Loaded: loaded (/lib/systemd/system/corridor-init-forwarding.service; enabled; vendor preset: enabled)
    Drop-In: /usr/lib/systemd/system/corridor-init-forwarding.service.d
             ������qubes-service.conf, qubes.conf
     Active: failed (Result: exit-code) since Mon 2022-11-07 16:52:36 EST; 1min 32s ago
       Docs: man:corridor(8)
    Process: 321 ExecStart=/usr/sbin/corridor-init-forwarding (code=exited, status=127)
   Main PID: 321 (code=exited, status=127)
        CPU: 0

Nov 07 16:52:36 localhost systemd[1]: Starting corridor's forwarding...
Nov 07 16:52:36 localhost corridor-init-forwarding[321]: /usr/sbin/corridor-i���nd
Nov 07 16:52:36 localhost systemd[1]: corridor-init-forwarding.service: Mai���/n/a
Nov 07 16:52:36 localhost systemd[1]: corridor-init-forwarding.service: Fai���de'.
Nov 07 16:52:36 localhost systemd[1]: Failed to start corridor's forwarding.
snat 
user@sys-corridor:~$ sudo systemctl --no-pager status corridor-init-snat
��� corridor-init-snat.service - corridor's source NAT
     Loaded: loaded (/lib/systemd/system/corridor-init-snat.service; enabled; vendor preset: enabled)
    Drop-In: /usr/lib/systemd/system/corridor-init-snat.service.d
             ������qubes-service.conf, qubes.conf
     Active: failed (Result: exit-code) since Mon 2022-11-07 16:52:37 EST; 3min 24s ago
       Docs: man:corridor(8)
    Process: 450 ExecStart=/usr/sbin/corridor-init-snat (code=exited, status=127)
   Main PID: 450 (code=exited, status=127)
        CPU: 0

Nov 07 16:52:37 sys-corridor systemd[1]: Starting corridor's source NAT...
Nov 07 16:52:37 sys-corridor corridor-init-snat[450]: /usr/sbin/corridor-init���nd
Nov 07 16:52:37 sys-corridor systemd[1]: corridor-init-snat.service: Main p���/n/a
Nov 07 16:52:37 sys-corridor systemd[1]: corridor-init-snat.service: Failed���de'.
Nov 07 16:52:37 sys-corridor systemd[1]: Failed to start corridor's source NAT.
Hint: Some lines were ellipsized, use -l to show in full.

As expected, neither disp-tor-browser can connect to tor when corridor is its netVM

13

And, it works. iptables didn’t exist in minimal template. After installing it in template, everything OK.

1 Like
14

Looks good. I wonder why it wouldn’t be mentioned as a temporary solution in the GitHub issue that I linked?

15

Actually, I won’t be running Corridor. A second Tor running is very identifiable to a network observer.

16

Because it is not in any way a solution to that problem.
Blocking all output from sys-net and sys-firewall is a solution.
But, you should make sure that no other qubes are connected to
sys-firewall, and that services that run on sys-net/sys-firewall have
been moved below the Tor Proxy.
And - the iptables rules are inadequate - fine to block OUTPUT using
external interface(s) but you should still allow lo.
And - don’t use iptables - use nftables instead. (You’re using
nftables anyway, so use it properly.)

I never presume to speak for the Qubes team.


When I comment in the Forum or in the mailing lists I speak for myself.

17

No need for a second tor instance running at the same time. You can either connect sys-whonix to it or if you know you’ll want to switch between a corridor instance and one unfiltered, create a sys-whonix-2 to connect to corridor and shut the main sys-whonix down when running. Possibilities are endless

1 Like
18

Corridor prevents all non-Tor traffic, that’s a pretty good solution in my eyes.

I’m not sure what you mean here? If they’re running in sys-net or sys-firewall then they are not going through the Tor proxy but that’s fine because they won’t have any outgoing traffic due to the firewall. Or are you saying move the services to VMs that do go through the Tor proxy? The main services are qubes-update-check and clocksync but you can get away without them when using this anonymous configuration.

Thanks.

Looks like nftables to me.

19

Updated rules

sudo nft add chain ip filter OUTPUT ‘{ policy drop; }’
sudo nft add rule ip filter OUTPUT oifname “lo” counter accept
sudo nft add rule ip filter OUTPUT counter drop

sudo nft add chain ip6 filter OUTPUT ‘{ policy drop; }’
sudo nft add rule ip6 filter OUTPUT oifname “lo” counter accept
sudo nft add rule ip6 filter OUTPUT counter drop

20

Hello There

I might be late and I’m kind of new to qubes I love it as it is but getting this to run I’m getting the following error

500 can’t connect to 127.0.0.1:8082 (connection refused) at usr/share/perl5/data.pm line 27.

Could maybe someone help?