Whonix-gw-17 not firing up network settings for whonix-ws-17

User Support General
,
1

Hi everyone,

since whonix-16 is EOL I’ve switched to whonix-17 two months ago.
In sys-whonix with template whonix-gateway-17 everthing is working correctly at first when it’s starting.

Problem: When I start a whonix-workstation-17 with sys-whonix as network gateway a few settings are not applied automatically in the sys-whonix qube, those are:

  1. The vifXX.0 (for example vif32.0) interface is being created in sys-whonix for a link to the workstation vm but the link status is down.
  2. The IP of sys-whonx is not being added to the vifXX.0 interface.
  3. The route to the whonix-workstation-17 qube on the vifXX.0 interface is not being added.

For example:

  1. sys-whonix is up and running and has established a TOR connection successfully. sys-whonix has 10.137.0.8 as its IP address.
  2. I fire up a whonix-workstation-17 disp VM from the whonix-ws-17-dvm Template. The disp vm has an IP address: 10.138.4.193
  3. Now I need to run the following very simple script in order to establish a connection to the sys-whonix qube from the disp vm.
# scriptname      interface       ip-address
./commands        vif32.0        10.138.4.193

#!/bin/bash
sudo ip link set $1 up && sudo ip addr add 10.137.0.8/32 dev $1 && sudo ip route add $2/32 dev $1

Does anyone know how to fix this? So that everything fires up with whonix-gateway-17 automatically? I installed the whonix-gateway-17 template already several times, but it’s always resulting in the same above described problem again.

2

Do you have Qubes OS 4.1 or Qubes OS 4.2?

3

Sorry I forgot to tell that I’m using Qubes 4.2.

4

Run this command in sys-whonix:

sudo journalctl -f

And then start new disposable whonix workstation.
Can you post the resulting sys-whonix log?

5

All right, thank you in advance!

journalctl -f in sys-whonix output is:

Apr 05 16:42:48 host kernel: vif vif-36-0 vif36.0: Guest Rx ready
Apr 05 16:42:56 host audit[4685]: USER_ACCT pid=4685 uid=1000 auid=4294967295 ses=4294967295 subj=unconfined msg='op=PAM:accounting grantors=pam_faillock,pam_permit acct="user" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Apr 05 16:42:56 host audit[4685]: USER_CMD pid=4685 uid=1000 auid=4294967295 ses=4294967295 subj=unconfined msg='cwd="/home/user" cmd=62617368202D63206563686F2022646973703339352073746174757322207C20746565202F72756E2F736477646174652D6775692F616E6F6E2D737461747573203E2F6465762F6E756C6C exe="/usr/bin/sudo" terminal=? res=success'
Apr 05 16:42:56 host sudo[4685]:     user : PWD=/home/user ; USER=sdwdate-gui ; COMMAND=/usr/bin/bash -c 'echo "disp395 status" | tee /run/sdwdate-gui/anon-status >/dev/null'
Apr 05 16:42:56 host audit[4685]: CRED_REFR pid=4685 uid=1000 auid=4294967295 ses=4294967295 subj=unconfined msg='op=PAM:setcred grantors=pam_faillock,pam_wheel,pam_permit acct="sdwdate-gui" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Apr 05 16:42:56 host sudo[4685]: pam_unix(sudo:session): session opened for user sdwdate-gui(uid=113) by (uid=1000)
Apr 05 16:42:56 host audit[4685]: USER_START pid=4685 uid=1000 auid=4294967295 ses=4294967295 subj=unconfined msg='op=PAM:session_open grantors=pam_limits,pam_permit,pam_unix,pam_tmpdir acct="sdwdate-gui" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Apr 05 16:42:56 host sudo[4685]: pam_unix(sudo:session): session closed for user sdwdate-gui
Apr 05 16:42:56 host audit[4685]: USER_END pid=4685 uid=1000 auid=4294967295 ses=4294967295 subj=unconfined msg='op=PAM:session_close grantors=pam_limits,pam_permit,pam_unix,pam_tmpdir acct="sdwdate-gui" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Apr 05 16:42:56 host audit[4685]: CRED_DISP pid=4685 uid=1000 auid=4294967295 ses=4294967295 subj=unconfined msg='op=PAM:setcred grantors=pam_faillock,pam_wheel,pam_permit acct="sdwdate-gui" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Apr 05 16:43:02 host audit[4711]: USER_ACCT pid=4711 uid=1000 auid=4294967295 ses=4294967295 subj=unconfined msg='op=PAM:accounting grantors=pam_faillock,pam_permit acct="user" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Apr 05 16:43:02 host audit[4711]: USER_CMD pid=4711 uid=1000 auid=4294967295 ses=4294967295 subj=unconfined msg='cwd="/home/user" cmd=62617368202D63206563686F2022646973703339352073746174757322207C20746565202F72756E2F736477646174652D6775692F616E6F6E2D737461747573203E2F6465762F6E756C6C exe="/usr/bin/sudo" terminal=? res=success'
Apr 05 16:43:02 host sudo[4711]:     user : PWD=/home/user ; USER=sdwdate-gui ; COMMAND=/usr/bin/bash -c 'echo "disp395 status" | tee /run/sdwdate-gui/anon-status >/dev/null'
Apr 05 16:43:02 host audit[4711]: CRED_REFR pid=4711 uid=1000 auid=4294967295 ses=4294967295 subj=unconfined msg='op=PAM:setcred grantors=pam_faillock,pam_wheel,pam_permit acct="sdwdate-gui" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Apr 05 16:43:02 host sudo[4711]: pam_unix(sudo:session): session opened for user sdwdate-gui(uid=113) by (uid=1000)
Apr 05 16:43:02 host audit[4711]: USER_START pid=4711 uid=1000 auid=4294967295 ses=4294967295 subj=unconfined msg='op=PAM:session_open grantors=pam_limits,pam_permit,pam_unix,pam_tmpdir acct="sdwdate-gui" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Apr 05 16:43:02 host sudo[4711]: pam_unix(sudo:session): session closed for user sdwdate-gui
Apr 05 16:43:02 host audit[4711]: USER_END pid=4711 uid=1000 auid=4294967295 ses=4294967295 subj=unconfined msg='op=PAM:session_close grantors=pam_limits,pam_permit,pam_unix,pam_tmpdir acct="sdwdate-gui" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Apr 05 16:43:02 host audit[4711]: CRED_DISP pid=4711 uid=1000 auid=4294967295 ses=4294967295 subj=unconfined msg='op=PAM:setcred grantors=pam_faillock,pam_wheel,pam_permit acct="sdwdate-gui" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
6

The log is normal, the same as in my working sys-whonix.
Did you upgrade your Qubes OS 4.2 in-place from Qubes OS 4.1?

7

Yes, I did an in-place upgrade from Qubes 4.1 to 4.2.

8

Not sure why is it happening. If you’ve installed whonix-17 templates from the Qubes OS repository and not upgraded them from whonix-16 templates in-place then everything should be working. I can only think that something broke during Qubes OS 4.1 → 4.2 upgrade.

9

I finally found the solution for this issue: If one has enabled IPv6 for sys-whonix, this very qube won’t receive routes through the qubes automation magic for this. One can still enable IPv6 but has to disable it for sys-whonix, by typing in dom0: qvm-features sys-whonix ipv6 ‘’

I reinstalled my Qubes and had IPv6 disabled at first and everything was running again, but when I switched to sys-net IPv6 enabled it was the same as with the installation back when I opened this thread. Now I remembered and finally after months found it!

1 Like