Can't get TemplateVM Update Proxy to work with Firewall or VPN NetVMs

Problem summary:

Setting dom0’s /etc/qubes-rpc/policy/qubes.UpdatesProxy AND /etc/qubes/policy.d/30-user.policy TemplateVM target to any NetVM other than a sys-wifi, sys-wired, sys-net, or sys-whonix results in one of two errors: “Reading from proxy failed - read (11: Resource temporarily unavailable) [IP: 127.0.0.1 8082]” OR “Reading from proxy failed - select (115: Operation now in progress) [IP: 127.0.0.1 8082]” (when the qubes-updates-proxy service has been added to the VPN or Firewall NetVM via dom0)

Objective summary:

I’d like to understand how the Update proxy mechanism works, because I thought I understood it, but I clearly don’t

Troubleshooting summary:

  • Cloned /etc/qubes/policy.d/90-default.policy as /etc/qubes/policy.d/30-user.policy according to best practices and verified permissions were identical (664)

  • sys-wifi and sys-wired were created as AppVMs (not cloned from sys-net) as HVM VMs that provide networking; sys-firewall is the stock firewall VM; sys-vpn leverages fedora’s native VPN facilities and did not require any additional packages; ALL NetVMs successfully provide expected connectivity to downstream Qubes

  • When dom0’s /etc/qubes-rpc/policy/qubes.UpdatesProxy AND /etc/qubes/policy.d/30-user.policy TemplateVM target is set to sys-wifi, sys-wired, sys-net, or sys-whonix TemplateVMs can immediately curl --proxy 127.0.0.1:8082/ <HTTPS target>, apt upgrade, and dnf upgrade successfully without restarting any Qube

  • When both of those files’ target is set to sys-firewall or sys-vpn, Template VMs are immediately unable to curl, apt, and dnf

    Reading from proxy failed - read (11: Resource temporarily unavailable) [IP: 127.0.0.1 8082]

  • ALL NetVMs are based on the same fedora-38-minimal template with the following packages installed: qubes-core-agent-networking, qubes-core-agent-network-manager, qubes-core-agent-dom0-updates, gnome-keyring, iproute, iputils, NetworkManager-wifi, network-manager-applet

  • NONE of the NetVMs appear to be running the qubes-updates-proxy (or anything like this) when querying services from dom0 via qvm-service <NETVM>

  • Only the non-VPN/firewall NetVMs appear to be running the qubes-updates-proxy when queried from within the NetVM itself via systemctl | grep update or systemctl status qubes-updates-proxy

  • When I enable qubes-updates-proxy on the VPN or firewall NetVM from dom0 via qvm-service <VPN NETVM> qubes-updates-proxy on (AND update the qubes.UpdatesProxy AND 30-user.policy files on dom0) subsequent TemplateVM updates take longer to fail, but eventually fail (“Reading from proxy failed - select (115: Operation now in progress) [IP: 127.0.0.1 8082]”) as does curl, even with the --insecure flag (“curl: (56) Received HTTP code 500 from proxy after CONNECT”)

  • Enabling qubes-updates-proxy via the Qube Manager GUI has the same effect

I don’t think this is a bug, I just think I’m missing something. I’ve scoured the forums and am out of ideas. I hope this is something simple.

Root cause:

IPv6 in WireGuard configuration

Troubleshooting summary:

  • To isolate the problem, I tried to
    • update the TemplateVM via the Qubes Manager GUI
    • curl through the UpdateProxy from the TemplateVM via curl --proxy 127.0.0.1:8082/ https://zx2c4.com/ip
  • I found that enabling the qubes-updates-proxy service on the VPN NETVM still caused the updates to fail, but curl would eventually succeed after a VERY long time. I came across another thread that suggested that IPv6 may be to blame. I created a similar NETVM and tested each step. When I imported the WireGuard configuration, the updates stopped working, so I figured the issue was with the VPN.

Resolution summary:

Basically, the VPN NETVM must have the

  • qubes-updates-proxy service added, to listen for connections configured in dom0’s /etc/qubes/policy.d/30-user.policy, either through
    • the GUI (<VPN NETVM> → Settings → Services (tab) → + Add) OR
    • dom0 via qvm-service <VPN NETVM> qubes-updates-proxy --enable
  • network-manager service added, to enable the WireGuard VPN connection to auto-start, either through
    • the GUI (<VPN NETVM> → Settings → Services (tab) → + Add) OR
    • dom0 via qvm-service <VPN NETVM> network-manager --enable
  • IPv6 method set to Disabled via <VPN TRAY ICON> → VPN Connections → Configure VPN… → WireGuard → wgcf-profile → <GEAR ICON> → IPv6 Settings (tab)

Next steps:

  • I’d be curious to know what it is about WireGuard and IPv6 that breaks apt and dnf updates.
1 Like