Templates incorrectly think they're not connected to a Whonix gateway.

I am off-and-on having this issue, and keep this thread around to remember how to resolve it.

However sudo /usr/lib/qubes-whonix/init/enable-firewall does not fix my issue. sudo touch /var/run/qubes-service/whonix-secure-proxy does, however.

Using Qubes R3.2 / Whonix 13?

Yes … Qubes R3.2 . Not sure how to check whonix release number.

I haven’t had this problem in a long time, but I always make sure to start sys-whonix separately and wait for the “Connected to Tor” message before starting a template.

This happens rarely in 2 situations for me:

  1. starting template too soon after starting gateway (as adw said)
  2. starting multiple templates at the same time

Problem seems to be fixed for me as well for about 4 months now.

Due to iptables block network access until sdwdate succeeded in Whonix 14, we’ll be using a much longer timeout (120 seconds) and attempts.

So any rare race conditions that may be left would be fixed as a byproduct of this.

Started having the same problem with whonix–ws template using Whonix 13.

This allows me to updates my template. Thanks!!

Here is the output of some of the commands you wanted if someone was still having issues…

 user@host:~$ sudo service qubes-whonix-torified-updates-proxy-check status
● qubes-whonix-torified-updates-proxy-check.service - Qubes Whonix Torified Updates Proxy Check
  Loaded: loaded (/lib/systemd/system/qubes-whonix-torified-updates-proxy-check.service; enabled; vendor preset: enabled)
  Active: active (exited) since Fri 2017-06-23 16:30:45 UTC; 7min ago
  Process: 1198 ExecStart=/usr/lib/qubes-whonix/init/torified-updates-proxy-check (code=exited, status=0/SUCCESS)
 Main PID: 1198 (code=exited, status=0/SUCCESS)
 CGroup: /system.slice/qubes-whonix-torified-updates-proxy-check.service

Jun 23 16:30:45 host torified-updates-proxy-check[1198]: + source /usr/lib/qubes-whonix/utility_functions.sh
Jun 23 16:30:45 host torified-updates-proxy-check[1198]: ++ PROXY_SERVER=http://10.137.255.254:8082/
Jun 23 16:30:45 host torified-updates-proxy-check[1198]: ++ PROXY_META='<meta name="application-name"      content="tor proxy"/>'
Jun 23 16:30:45 host torified-updates-proxy-check[1198]: ++ UWT_DEV_PASSTHROUGH=1
Jun 23 16:30:45 host torified-updates-proxy-check[1198]: ++ curl --silent --connect-timeout 10     http://10.137.255.254:8082/
Jun 23 16:30:45 host torified-updates-proxy-check[1198]: + curl_output=
Jun 23 16:30:45 host torified-updates-proxy-check[1198]: + true
Jun 23 16:30:45 host torified-updates-proxy-check[1198]: + grep -q '<meta name="application-name" content="tor proxy"/>'
Jun 23 16:30:45 host torified-updates-proxy-check[1198]: + echo ''
Jun 23 16:30:45 host systemd[1]: Started Qubes Whonix Torified Updates Proxy Check.

user@host:~$ sudo rm /var/run/qubes-service/whonix-secure-proxy
rm: cannot remove ‘/var/run/qubes-service/whonix-secure-proxy’: No such file or directory

user@host:~$ sudo bash -x /usr/lib/qubes-whonix/init/torified-updates-proxy-check
+ set -x
++ qubesdb-read /qubes-vm-type
+ qubes_vm_type=TemplateVM
+ '[' '!' TemplateVM = TemplateVM ']'
+ '[' -e /var/run/qubes-service/whonix-secure-proxy ']'
+ source /usr/lib/qubes-whonix/utility_functions.sh
++ PROXY_SERVER=http://10.137.255.254:8082/
++ PROXY_META='<meta name="application-name" content="tor proxy"/>'
++ UWT_DEV_PASSTHROUGH=1
++ curl --silent --connect-timeout 10 http://10.137.255.254:8082/
+ curl_output='<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

<head>
<title>403 Filtered</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="application-name" content="tor proxy"/>
</head>

<body>

<h1>Filtered</h1>

<p>The request you made has been filtered</p>

<hr />

<p><em>Generated by <a href="https://banu.com/tinyproxy/">tinyproxy</a> version 1.8.3.</em></p>

</body>

</html>'
+ echo '<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

<head>
<title>403 Filtered</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="application-name" content="tor proxy"/>
</head>

<body>

<h1>Filtered</h1>

<p>The request you made has been filtered</p>

<hr />

<p><em>Generated by <a href="https://banu.com/tinyproxy/">tinyproxy</a> version 1.8.3.</em></p>

</body>

</html>'
+ grep -q '<meta name="application-name" content="tor proxy"/>'
+ touch /var/run/qubes-service/whonix-secure-proxy

user@host:~$ whonixcheck
[INFO] [whonixcheck] whonix-ws-clone | Whonix-Workstation | TemplateVM | Fri Jun 23 16:50:34 UTC 2017
[INFO] [whonixcheck] Connected to Tor.
[ERROR] [whonixcheck] Systemd Clock Check Result: 
Unexpected results by timedatectl.
timedatectl_output_pretty:
      Local time: Fri 2017-06-23 16:50:35 UTC
 Universal time: Fri 2017-06-23 16:50:35 UTC
      RTC time: n/a
     Time zone: Etc/UTC (UTC, +0000)
 Network time on: yes
NTP synchronized: no
 RTC in local TZ: no
It is generally recommended to keep the default as per Whonix Design. [1]

If you using electrum and apt pinning as described in Anonymous Money. Then congrats you, you system is broken and you can be compromised. Many packets in system now installed from backports repo. Because now Debian 8 jessie named “oldstable”, and not “stable” as described in guide.

If anybody can, please check Anonymous Money apt-pinning recommendations and fix it.

And also in suggested pinning config, i don’t find any pinning settings for whonix and qubes repo, that might be reason for any unpredicted behaviors on updates.

When system updated from “backports”, you have two indicators of this:

  1. Error “Unexpected results by timedatectl” (when running whonixcheck)
  2. Error “Whonix-Gateway NetVM required for updates!” on template startup

//cc @HulaHoop

Do we even need /etc/apt/preferences.d/debian-pinning.pref? Isn’t this working fine without it?

  1. I haven’t tested the Electrum version out on Stretch yet to know if backports are still needed now or will be soon.

Then congrats you, you system is broken and you can be compromised. Many packets in system now installed from backports repo. Because now Debian 8 jessie named “oldstable”, and not “stable” as described in guide.

Source? Its the first time I hear that apt can be compromised just by using pinning. Unless you mean its an old package that no longer receives sec updates - that would make more sense.

HulaHoop:

  1. I haven’t tested the Electrum version out on Stretch yet to know
    if backports are still needed now or will be soon.

Unrelated. Backports not needed in stretch. (Tested by me.)

This is about Whonix 14 / jessie based. The argument is, that
/etc/apt/preferences.d/debian-pinning.pref either/and/or Pin: release a=stable / Pin: release a=testing is causing Whonix 13 stable
upgrades of Debian packages to break Whonix. Installs a newer kernel
which then breaks it.

https://forums.whonix.org/t/critical-x-wont-start-after-yesterdays-debian-upgrade

cc’d you, because you originally added debian-pinning.pref.

Then congrats you, you system is broken and you can be compromised.
Many packets in system now installed from backports repo. Because
now Debian 8 jessie named “oldstable”, and not “stable” as
described in guide.

Source? Its the first time I hear that apt can be compromised just by
using pinning. Unless you mean its an old package that no longer
receives sec updates - that would make more sense.

Compromised might be the wrong word here. Not in a sense that a third
party can access/control your Whonix VM. But serious nonetheless.
Rendering Whonix unbootable.

OK so should I deprecate the current instruction set and recommend sudo apt-get install electrum?

Pretty serious indeed. I think I threw out a lot of apt pinning install instructions over time but thats the most important one left.

HulaHoop:

[quote=“Patrick, post:31, topic:2258”] Unrelated. Backports not
needed in stretch. (Tested by me.) [/quote]

OK so should I deprecate the current instruction set and recommend
sudo apt-get install electrum?

No, because Whonix is still based on jessie, not stretch. (Whonix 14
release not done.)

[quote=“Patrick, post:31, topic:2258”] This is about Whonix 14 /
jessie based. The argument is, that
/etc/apt/preferences.d/debian-pinning.pref either/and/or Pin:
release a=stable/Pin: release a=testing is causing Whonix 13 stable
upgrades of Debian packages to break Whonix. Installs a newer kernel
which then breaks it. [/quote]

Pretty serious indeed. I think I threw out a lot of apt pinning
install instructions over time but thats the most important one
left.

Any reason to keep /etc/apt/preferences.d/debian-pinning.pref?

If we need to keep it, we’d need to use specific codenames (such as
jessie) and not generic ones (such as stable, since they can change
meaning and break things).

1 Like

Hi there,

I’ve got both symptoms as well (Error “Unexpected results by timedatectl” (when running whonixcheck) and Error “Whonix-Gateway NetVM required for updates!” on template startup)

Looks like you guys found the reason but I couldn’t find any solution.
Should I reinstall whonix templates ?

thank you

Hello,

Am still unable to update whonix (couldn’t find how to check which version I run) on Qubes 3.2.

I followed the apt-pinning instruction to run electrum.
Any help would be appreciated !

Getting same message as above while trying to check workstation:
Whonix-Gateway NetVM required for updates!
Please ensure that this TemplateVM has a Whonix-Gateway as its NetVM.
No updates are possible without an active (running) Whonix-Gateway VM.

Running whonixcheck in terminal on workstation:
user@host:~$ whonixcheck
[INFO] [whonixcheck] whonix-ws | Whonix-Workstation | TemplateVM | Sun Aug 13 12:02:05 UTC 2017
[INFO] [whonixcheck] Connected to Tor.
[ERROR] [whonixcheck] Systemd Clock Check Result:
Unexpected results by timedatectl.
timedatectl_output_pretty:
Local time: Sun 2017-08-13 12:02:11 UTC
Universal time: Sun 2017-08-13 12:02:11 UTC
RTC time: n/a
Time zone: Etc/UTC (UTC, +0000)
Network time on: yes
NTP synchronized: no
RTC in local TZ: no
It is generally recommended to keep the default as per Whonix Design. [1]
If you did not change timezone related settings, please report this Whonix bug.
If you know what you are doing and changed this on purpose, feel free to
disable this check. [2]

[1] Whonix ™ Networking Implementation Documentation
[2] Create a file /etc/whonix.d/50_whonixcheck_user and add:
whonixcheck_skip_functions+=" check_systemd_clock "

user@host:~$ sudo service qubes-whonix-torified-updates-proxy-check status
● qubes-whonix-torified-updates-proxy-check.service - Qubes Whonix Torified Updates Proxy Check
Loaded: loaded (/lib/systemd/system/qubes-whonix-torified-updates-proxy-check.service; enabled; vendor preset: enabled)
Active: active (exited) since Sun 2017-08-13 11:56:02 UTC; 23min ago
Process: 1101 ExecStart=/usr/lib/qubes-whonix/init/torified-updates-proxy-check (code=exited, status=0/SUCCESS)
Main PID: 1101 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/qubes-whonix-torified-updates-proxy-check.service

Aug 13 11:56:02 host torified-updates-proxy-check[1101]: + source /usr/lib/qubes-whonix/utility_functions.sh
Aug 13 11:56:02 host torified-updates-proxy-check[1101]: ++ PROXY_SERVER=http://10.137.255.254:8082/
Aug 13 11:56:02 host torified-updates-proxy-check[1101]: ++ PROXY_META=‘’
Aug 13 11:56:02 host torified-updates-proxy-check[1101]: ++ UWT_DEV_PASSTHROUGH=1
Aug 13 11:56:02 host torified-updates-proxy-check[1101]: ++ curl --silent --connect-timeout 10 http://10.137.255.254:8082/
Aug 13 11:56:02 host torified-updates-proxy-check[1101]: + curl_output=
Aug 13 11:56:02 host torified-updates-proxy-check[1101]: + true
Aug 13 11:56:02 host torified-updates-proxy-check[1101]: + grep -q ‘’
Aug 13 11:56:02 host torified-updates-proxy-check[1101]: + echo ‘’
Aug 13 11:56:02 host systemd[1]: Started Qubes Whonix Torified Updates Proxy Check.

user@host:~$ ls -la /var/run/qubes-service/whonix-secure-proxy
-rw-rw-r-- 1 root root 0 Aug 13 12:14 /var/run/qubes-service/whonix-secure-proxy

user@host:~$ sudo rm /var/run/qubes-service/whonix-secure-proxy

user@host:~$ sudo bash -x /usr/lib/qubes-whonix/init/torified-updates-proxy-check

  • set -x
    ++ qubesdb-read /qubes-vm-type
  • qubes_vm_type=TemplateVM
  • ‘[’ ‘!’ TemplateVM = TemplateVM ‘]’
  • ‘[’ -e /var/run/qubes-service/whonix-secure-proxy ‘]’
  • source /usr/lib/qubes-whonix/utility_functions.sh
    ++ PROXY_SERVER=http://10.137.255.254:8082/
    ++ PROXY_META=‘’
    ++ UWT_DEV_PASSTHROUGH=1
    ++ curl --silent --connect-timeout 10 http://10.137.255.254:8082/
  • curl_output='<?xml version="1.0" encoding="UTF-8" ?>
403 Filtered

Filtered

The request you made has been filtered


Generated by tinyproxy version 1.8.3.

' + echo '<?xml version="1.0" encoding="UTF-8" ?> 403 Filtered

Filtered

The request you made has been filtered


Generated by tinyproxy version 1.8.3.

' + grep -q '' + touch /var/run/qubes-service/whonix-secure-proxy

thank you very much for any insight about how to fix this.

Have you tired this:

It worked for me although I didn’t follow the apt-pinning instructions for electrum. The only error I had was ‘‘whonix-gateway netvm required for updates’’ so it will only help with updating your whonix templates.