How to identify which template requested to use the update proxy?

Problem: every client has the same ip, localhost

First, templates are network isolated by default and only can use the update proxy done with permanent port binding - QubesOS Firewall Docs
Some important files:

  • /etc/qubes-rpc/policy/qubes.UpdatesProxy
  • /lib/systemd/system/qubes-updates-proxy-forwarder@.service
  • /lib/systemd/system/qubes-updates-proxy-forwarder.socket
  • /lib/systemd/system/qubes-updates-proxy.service
  • /etc/tinyproxy/tinyproxy-updates.conf
  • /etc/tinyproxy/updates-blacklist

The problem is that as it is reaching directly to localhost, different templates requests will have the same client ip (

CONNECT   Jul redacted [495424]: Connect (file descriptor 10): localhost []
CONNECT   Jul redacted [495424]: Request (file descriptor 10): GET http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/vm/dists/bullseye/InRelease HTTP/1.1
INFO      Jul redacted [495424]: No upstream proxy for deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion
INFO      Jul redacted [495424]: opensock: opening connection to deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion:80
INFO      Jul redacted [495424]: opensock: getaddrinfo returned for deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion:80
CONNECT   Jul redacted [495424]: Established connection to host "deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion" using file descriptor 11.
INFO      Jul redacted [494774]: Closed connection between local client (fd:10) and remote client (fd:11)

So every client gets the same ip.

Maybe solution? IDK

I am thinking of using virtual interfaces to connect templates to the update proxy vm, but don’t know if it is recommended as templates are non networked by default and this needs to be done by someone more experienced with networking than me.

Use case: identify misuse of the proxy

This can help if monitor tinyproxy logs to identify which qube made the request to the tinyproxy proxy, so it can identify templates that are reaching unwanted domains, maybe leaks, maybe compromised…
So when this is identified, it can be corrected on the cliend_addr qube, but for know it is unkown as every client is

Use case: is stream isolation:

Whonix apt-get stream isolation thread, this is not a whonix issue, as the problem is in tinyproxy not getting the correct client addr as everything is coming from localhost. That is why SocksPort IsolateClientAddr doesn’t matter as of know as.

DNS requests use first the clien addr as
Establishing connections uses the update proxy qubesdb ip (sys-whonix qube ip)

Note the Client port and Target:
Circuit reuse:

    ID Purpose              Client                CircID CircPurpose          Target                                                        
  2161 USER               2137 HS_CLIENT_REND                  
  2165 USER               2137 HS_CLIENT_REND
    ID Purpose              Client                CircID CircPurpose          Target                                                        
  2157 DNS_REQUEST         2122 GENERAL                                
  2158 DNS_REQUEST         2122 GENERAL                                                  
  2161 USER               2137 HS_CLIENT_REND
  2162 USER               2032 GENERAL                              
  2165 USER               2137 HS_CLIENT_REND

I am expecting qubes update to show the tinyproxy client addr so stream can get isolated. For example, this is how 2 anon-whonix appvms (not templates) are identified with different client_addr by the same gateway (no circuit reuse because of SocksPort IsolateClientAddr):
The client addr are the ws qube ips.

    ID Purpose              Client                CircID CircPurpose          Target                                                        
  2235 USER              2146 HS_CLIENT_REND       5ajw6aqf3ep7sijnscdzw77t7xq4xjpsy335yb2wiwgouo7yfxtjlmid.onion:80
  2236 USER              2151 HS_CLIENT_REND       qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion:80
  2237 USER              2166 HS_CLIENT_REND       dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion:80
  2238 USER              2153 HS_CLIENT_REND       2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion:80
  2239 USER            2156 HS_CLIENT_REND       qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion:80
  2240 USER            2175 HS_CLIENT_REND       dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion:80
  2241 USER            2165 HS_CLIENT_REND       2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion:80
  2242 USER            2174 HS_CLIENT_REND       5ajw6aqf3ep7sijnscdzw77t7xq4xjpsy335yb2wiwgouo7yfxtjlmid.onion:80