Denied: qubes.UpdatesProxy

When trying to update TemplateVM I get this warning, that the connection to the Update Proxy is denied.

My system:

### Qubes Dom0 (Qubes R4.1)
[user@dom0 ~]$ uname -a 
Linux dom0 5.10.8-1.qubes.x86_64 #1 SMP Mon Jan 18 18:24:01 CET 2021 x86_64 x86_64 x86_64 GNU/Linux

### Update VM (sys-whonix)
user@host:~$ uname -a
Linux host 5.4.61-1.qubes.x86_64 #1 SMP Thu Sep 17 01:09:48 UTC 2020 x86_64 GNU/Linux

Anyone else with this issue?

Any specific information that I should provide?


EDIT: Some information:

qubes.UpdatesProxy policy

[user@dom0 ~]$ cat /etc/qubes-rpc/policy/qubes.UpdatesProxy 
$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm $anyvm deny

qubesctl [...] update.qubes-vm

[user@dom0 ~]$ sudo qubesctl --skip-dom0 --targets=fedora-32 --show-output state.sls update.qubes-vm
fedora-32:
  ----------
            ID: dnf list updates --refresh >/dev/null
      Function: cmd.run
        Result: False
       Comment: Command "dnf list updates --refresh >/dev/null" run
       Started: 22:40:23.101185
      Duration: 3238.605 ms
       Changes:   
                ----------
                pid:
                    1151
                retcode:
                    1
                stderr:
                    Errors during downloading metadata for repository 'fedora-cisco-openh264':
                      - Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64 [Recv failure: Connection reset by peer]
                    Error: Failed to download metadata for repo 'fedora-cisco-openh264': Cannot prepare internal mirrorlist: Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64 [Recv failure: Connection reset by peer]
                    Errors during downloading metadata for repository 'fedora-modular':
                      - Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64 [Recv failure: Connection reset by peer]
                    Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare internal mirrorlist: Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64 [Recv failure: Connection reset by peer]
                stdout:
  ----------
            ID: update
      Function: pkg.uptodate
        Result: True
       Comment: System is already up-to-date
       Started: 22:40:29.468223
      Duration: 2599.923 ms
       Changes:   
  ----------
            ID: notify-updates
      Function: cmd.run
          Name: /usr/lib/qubes/upgrades-status-notify
        Result: False
       Comment: Command "/usr/lib/qubes/upgrades-status-notify" run
       Started: 22:40:32.068342
      Duration: 1361.085 ms
       Changes:   
                ----------
                pid:
                    1306
                retcode:
                    1
                stderr:
                stdout:
  
  Summary for fedora-32
  ------------
  Succeeded: 1 (changed=2)
  Failed:    2
  ------------
  Total states run:     3
  Total run time:   7.200 s

Still no real clue why this might be happening.

5 Likes

Did you ever figure this out? Im getting this all day.

OP’s UpdateProxy policy is missing rules for non-Whonix VMs. The rules say that any VMs with tag whonix-updateVM would use sys-whonix as their UpdateVM, but there are no rules that would match other templates that don’t have that tag.

Assuming you want to update the other templates using sys-net, two more lines could be added:

@type:template @default allow,target=sys-net
@anyvm @anyvm deny

This is explained in more detail here: How to install software | Qubes OS

1 Like

This isn’t right in 4.1.
The policy file framework has been updated to use a default unified file
under /etc/qubes/policy.d/90-default.policy.
If you want to make changes to the default policy, you create a NEW
policy file in that directory, numerically lower, and that will override
the default.
That separate Whonix file is unnecessary, since it is using the old,
deprecated, form, which will be used under 4.X, but dropped in 5.0. Whonix
treatment is correctly set in the default file.

SO, to anyone having this problem, let’s get some hard information:

  1. Confirm which version of Qubes you are using.
  2. Does the error affect all templates? If not, which are affected?
  3. For templates which show the error, what is the output of qvm-tags?
  4. Are you updating over Whonix?
  5. Have you made any changes to default policy?
  6. What template are you using for the UpdateProxy - by default this
    will be sys-net unless you opted to update all templates over Tor.
3 Likes

I have the same issue. I’m using Qubes 4.1. The error is: Denied: whonix.NewStatus. It happens when I open the whonix-gw-16 template, whonix-ws-16 template and any other VM based on whonix-gw-16 or whonix-ws-16. Never changed any policy, Just updated all vms. The error appears when shut down or start a vm(based on whonix templates). I’m not updating over tor.

Same issue here after cloning sys-net to seperate wireless and wired connectivity.
Nothing can update except dom0. No idea what to do. Default Fedora-34 AppVMs still have connectivity but AppVM’s based on minimal templates do not even connect to internet anymore.
Feels like a global pref issue but can’t find nor do I know Qubes enough to know what is wrong.

Yet no one expecting @unman’s help to specifically answer his questions.

Same Issue here after deleting sys-net and creating sys-net-lan and sys-net-wlan. Fresh 4.1 install Debian templates only.
I also edit /etc/qubes/policy.d/90-default.policy and changed
qubes.UpdateProxy * @type:TemplateVM @default allow target=sys-net
to
qubes.UpdateProxy * @type:TemplateVM @default allow target=sys-net-wlan

I stumbled upon this bug a day before and thought i somehow trashed my qubes install (playing a lot with saltstack latley) so i did a fresh install yesterday, but now its there again…
Maybee i missed something in the minimal templates to install, but even if i switch apvm templates back to default debian-11 the error seems to persist.

Thanks for any help on this

Still can’t figure this one out.

Anyone know how to create sys-net and sys-firewall from scratch without full reinstall. qvm-create commands I find don’t work on 4.1…

Thanks!

Thanks

some progress here, at least template updates are working if i activate the “qubes-updates-proxy” service in the qube thats defined in /etc/qubes/policy.d/90-default.rule

SO, to anyone having this problem, let’s get some hard information:

Confirm which version of Qubes you are using.    **4.1.1**

Does the error affect all templates?  **yes**

For templates which show the error, what is the output of qvm-tags? **cannot update repo**

Are you updating over Whonix?  **whatever is default**

Have you made any changes to default policy? **not to my knowledge**

What template are you using for the UpdateProxy - by default this will be sys-net unless you opted to update all templates over Tor.  **default**

I had this problem when I installed Qubes without the Whonix template pre-installed and update over Tor was selected.

sudo nano /etc/qubes-rpc/policy/qubes.UpdatesProxy

Then enter:
@type:TemplateVM @default allow,target=sys-whonix
@type:TemplateVM @anyvm deny
@tag:whonix-updatevm @default allow,target=sys-whonix
@tag:whonix-updatevm @anyvm deny
@type:StandaloneVM @default allow,target=sys-whonix
@type:StandaloneVM @anyvm deny

And save the file.

Thus, I think the above solutions don’t get generated in the etc/qubes-rpc/policy/qubes.UpdatePolicy file, causing the error.

1 Like

Thank you for reply joe,
still get the error after reboot. There was already one line
in qubes.UpdatesProxy:
$type:TemplateVM $default allow,target=sys-vpn
Should I delete that and only keep your six lines?

Following this from whonix aboout UpdatesProxy:
**_At the very top_of that file you should have the following: **
$tag:whonix-updatevm $default allow, target=sys-whonix
whonix now updates, but fedora-36, debial-11, kali, and
gentoo-xfce still fail to update.

These are the generated lines during the install:
$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm @anyvm deny
$type:TemplateVM $default allow,target=sys-whonix

The six lines earlier was a larger selection.

Try deleting the sys-vpn line. Check your Global Settings. You might have selected sys-vpn in your Global Settings. Maybe it’s a conflict with sys-whonix.

Thank you Joe.
That worked for all qubes except kali and gentoo, so I just deleted them.
My UpdatesProxy now has 8 lines - seems duplicate but for the $ and @
and tag and type:
**
$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:TemplateVM @default allow,target=sys-whonix
$tag:TemplateVM @anyvm deny
$type:TemplateVM $default allow,target=sys-whonix
@tag:whonix-updatevm @default allow,target=sys-whonix
@tag:whonix-updatevm @anyvm deny
@type:StandaloneVM @default allow,target=sys-whonix
@type:StandaloneVM @anyvm deny
**

Its nice to not see all those errors pop up. Thank you!

Why do you still insist on qubes.UpdatesProxy, and especially using legacy and new tags?

# HTTP proxy for downloading updates
# Upgrade Whonix TemplateVMs through sys-whonix.
qubes.UpdatesProxy      *   @tag:whonix-updatevm    @default    allow target=sys-whonix
# Deny Whonix TemplateVMs using UpdatesProxy of any other VM.
qubes.UpdatesProxy      *   @tag:whonix-updatevm    @anyvm      deny
# Upgrade all TemplateVMs through sys-whonix or cacher.
 qubes.UpdatesProxy     *    @type:TemplateVM        @default    allow target=cacher
# Default rule for all TemplateVMs - direct the connection to sys-net-dvm or cacher
qubes.UpdatesProxy      *   @type:TemplateVM        @default    allow target=cacher
qubes.UpdatesProxy      *   @anyvm                  @anyvm      deny

Immediately when starting the Whonix WorkSpace 16 qube, after the Whonix GateWay 16 qube started successfull.

Denied: qubes.UpdatesProxy
Denied qubes.UpdatesProxy from whonix-ws-16 to

Whonix-Gateway (sys-whonix) required for updates!
Please ensure that whonix-gw TemplateBasedVM sys-whonix exists.
No updates are possible without an active (running) Whonix-Gateway VM.

Completely fresh Qubes OS installation, only Whonix templates installed. Not even trying to update yet, only launch Whonix.

Qubes R4.1.1 x86_64

Don’t know, only Whonix 16 templates (GateWay and WorkSpace) installed

qvm-tags: command not found

Installing off a fresh Qubes ISO USB.

Since not sure what that means, I guess not(?)

If thats true when only Whonix templates installed, then I guess sys-net(?)

In dom0

Do you have sys-whonix, and is it started? To me it looks like you started whonix-gw-16 which is template and no template provides network. AppVm based on that template named sys-whonix provides network and possibility to update.

if you had sys-whonix but you renamed it, then you have to change correspondent entries in `/etc/qubes/policy.d/90-default.policy

You’d want instead to create let’s say 30-user.policy with the content above, for example, just rename sys-whonix with the name you gave to it. I haven’t tested if renaimg is allowed for sys-whonix in order update to properly work, so if it doesn’t then try to name it back to sys-whonix.

None of this is guaranteed, it’s just my thoughts on the issue. Further info needed probably for better diagnostics.

You make a distinction between sys-whonix and whonix-gw-16 that the installer does not. Under initial setup → configuration whonix-gw-16 and whonix-ws-16 seem identified with sys-whonix and anon-whonix respectively:

Create Whonix Gateway and Workstation qubes (sys-whonix, anon-whonix)

Since it said whonix-gw-16 started successfully, I assumed I could start whonix-ws-16 without further steps. But you are saying I need to start sys-whonix manually first? How can I do that? I have not renamed it as far as I know.

Also important is that when you install only Whonix templates (no Fedora and Debian), most configuration options get greyed out, including “Create Whonix Gateway and Workstation qubes (sys-whonix, anon-whonix)”. I assumed that option was necessarily implied by installing only Whonix templates, but now I am second guessing myself. Could it be that sys-whonix and anon-whonix, and also sys-net, sys-firewall and sys-usb, are not created unless a Debian or Fedora qube is also installed?