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:
- 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.
- The IP of sys-whonx is not being added to the vifXX.0 interface.
- The route to the whonix-workstation-17 qube on the vifXX.0 interface is not being added.
For example:
- sys-whonix is up and running and has established a TOR connection successfully. sys-whonix has 10.137.0.8 as its IP address.
- 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
- 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.
Do you have Qubes OS 4.1 or Qubes OS 4.2?
Sorry I forgot to tell that I’m using Qubes 4.2.
Run this command in sys-whonix:
sudo journalctl -f
And then start new disposable whonix workstation.
Can you post the resulting sys-whonix log?
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'
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?
Yes, I did an in-place upgrade from Qubes 4.1 to 4.2.
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.
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