I think you are confused between the processes for using the caching
proxy over qrexec, (as for templates), and using it over normal
Looking at your extensive notes, I see that you have adopted a
scattergun approach, trying many different things and changing your
targets and configuration. It’s much better to identify a specific aim,
and focus on solving that specific problem. To do this, break down your
major task in to small steps and solve each step at a time.
Don’t mix in bind-dirs at this stage - don’t switch the target - take
Access using normal networking.
To access the proxy using normal Qubes networking, you specify the
actual IP address of the proxy in the
To be processed by apt processes, this file should be in
Write that file (the contents you show look right to me.)
Set the caching proxy as the netvm of your debian-11-test qube.
sudo apt update
This should work - if it doesn’t, check the IP address you specified
If apt update still does not work, see if you can access
http://10.y.y.y:8082 in a browser. You should see a configuration
window. If you don’t, it suggests that either apt-cacher-ng is not running,
access is blocked via nftables, the IP address is incorrect, or you have
not set the proxy as netvm.
Solve that problem: the sensible place to start would be to work in the proxy
qube. You can check the status using
systemctl status apt-cacher-ng,
and check availability by pointing a browser at the same address.
If the service is running, make sure that you have a rule in the INPUT
chain giving access to tcp port 8082, by specifying
ACCEPT tcp dpt:8082
You can check this by running
sudo iptables -L -nv.
If you do not have such a rule, add one:
sudo iptables -I INPUT -p tcp --dport 8082 -j ACCEPT
Test again from the proxy
Test again from debian-11-test
Access using normal networking, where the proxy is not direct netvm.
- Once you have the first case working, create a new qube with
provides_network set, and the proxy as netvm.
- Set this qube as the netvm for debian-11-test.
- Confirm you can access the proxy from this new qube. (Steps as
- Confirm you can access the proxy from debian-11-test.
This configuration will work provided that the intermediate qube is not
encrypting the traffic or routing it elsewhere - a VPN or Tor proxy
will do this, so don’t put them in the netvm chain.
You can use apt-cacher-ng as a drop in replacement for tinyproxy,
so you can run it on e.g. sys-firewall.
If you want to do this, make sure that you have disabled the tinyproxy
service, and that the caching proxy service is able to start and run.
Access using qrexec
This is the method used by templates, but you can apply it to any qube.
updates-proxy-setup creates a listening service at 127.0.0.1:8082,
which forwards traffic over qrexec to the target.
The target is specified in dom0, in 4.0 using /etc/qubes-rpc/policy/qubes.UpdatesProxy,
and in 4.1 by a policy file in /etc/qubes/policy.d
To make this work in a qube:
- Begin with a clean qube.
- Enable the
- Start the qube.
- Confirm that the service is running:
systemctl status qubes-updates-proxy-forwarder.socket
- The service should show “active(listening)” - if it does not, solve
that problem. Attempt to manually start the service, and check the
- Confirm that the file has been created at
/etc/apt/apt.conf.d/01qubes-proxy specifying the proxy at
- Make sure that you have an entry in the relevant policy file for this
new qube, pointing to the caching proxy. (In 4.1 it’s recommended that
you create a new policy file in the same location with a lower number _
e.g 30_user.policy - to hold custom changes to the policy.)
The syntax is slightly different between 4.0 and 4.1, so make sure you
sue the right form.
In 4.1 it would look like
TEST @default allow target=CACHING_PROXY -
change the uppercase to match you setup.
sudo apt update
Don’t have TWO proxy specifications in
/etc/apt/apt.conf.d/ - that’s
confusing for you and for your qubes.
Break down your target in to small steps.
Keep the specification of the target and of each step as minimal as
Focus on solving each small step in order.
Once you have solved one, move on to the next.
When you have reached the target, you may want to add more steps - e.g.
in this case adding bind-dirs. That is not necessary to start with.
It takes some time to learn how to do this, particularly in Qubes,
I never presume to speak for the Qubes team.
where there may be many confounding factors.
It also takes time to learn what steps are needed
to reach a certain target: this can lead to XY problems.
That’s fine - everyone starts somewhere.
If you need help ask - it’s helpful for people to say how the system is
configured, what they want to achieve, what steps they have taken so
far, and where they are stuck.
When I comment in the Forum or in the mailing lists I speak for myself.