Qubes in a corporate network behind HTTP proxy [R4.0.x]

[pr0xy]

I have been running R3.2 for about as long as I can. Time to upgrade to
R4.0.x

Original 2017 thread where I got this working in R3.2:
https://groups.google.com/d/msg/qubes-users/K_etKdhnqLA/KyJ16z8JCwAJ

It appears that some of the R3.2 tweaks I used to get Qubes to work
nicely with my corporate proxy are no longer valid in 4.0.x. To
summarize, my company network has a very restrictive proxy that forces
internet traffic through an HTTP/HTTPS proxy like:

proxy.example.com:8080

In R4.0.x how and where would I set this proxy for the Qubes Updates
Proxy? sys-net? sys-firewall? TemplateVMs?

[pr0xy]

If I understand the documentation correctly...
https://qubes-os.org/doc/software-update-domu/#updates-proxy
we have TinyProxy running in sys-net, and this proxy is used for
TemplateVM updates.

In the default R4.0.3 install, sys-net is based on a Fedora 30 template.
In the fedora-30 templateVM I tried editing
/etc/tinyproxy/tinyproxy.conf to add the IP of my company's HTTP proxy
as the upstream proxy

Upstream http 10.0.0.1:8080

That does not seem to work.

In R3.2 I could switch the NetVM of a template to something that worked,
like sys-whonix. That doesn't seem to work in R4.x. At the moment I
cannot update dom0 or other templates aside from Whonix.

[unman]

On Wed, Jul 15, 2020 at 11:41:57PM -0700, pr0xy wrote:
> On 2020-07-15 09:28, pr0xy wrote:
> > I have been running R3.2 for about as long as I can. Time to upgrade to
> > R4.0.x
> >
> > Original 2017 thread where I got this working in R3.2:
> > https://groups.google.com/d/msg/qubes-users/K_etKdhnqLA/KyJ16z8JCwAJ
> >
> > It appears that some of the R3.2 tweaks I used to get Qubes to work
> > nicely with my corporate proxy are no longer valid in 4.0.x. To
> > summarize, my company network has a very restrictive proxy that forces
> > internet traffic through an HTTP/HTTPS proxy like:
> >
> > proxy.example.com:8080
> >
> > In R4.0.x how and where would I set this proxy for the Qubes Updates
> > Proxy? sys-net? sys-firewall? TemplateVMs?
>
> If I understand the documentation correctly...
> https://qubes-os.org/doc/software-update-domu/#updates-proxy
> we have TinyProxy running in sys-net, and this proxy is used for
> TemplateVM updates.
>
> In the default R4.0.3 install, sys-net is based on a Fedora 30 template.
> In the fedora-30 templateVM I tried editing
> /etc/tinyproxy/tinyproxy.conf to add the IP of my company's HTTP proxy
> as the upstream proxy
>
> Upstream http 10.0.0.1:8080
>
> That does not seem to work.

It would be helpful if you said in what way it does not seem to work.

Check in dom0, the contents of /etc/qubes-rpc/policy/qubes.UpdatesProxy,
to make sure which qube is acting as the proxy.
Check in a template if you are using sources with http:// or https:// -
look in /etc/yum.repos.d or /etc/apt/sources.list as appropriate
Confirm that you have DNS resolving in whichever qube is acting as
proxy.

Report back.

[awokd]

unman:

> On Wed, Jul 15, 2020 at 11:41:57PM -0700, pr0xy wrote:
>> On 2020-07-15 09:28, pr0xy wrote:

>>> proxy.example.com:8080
>>>
>>> In R4.0.x how and where would I set this proxy for the Qubes Updates
>>> Proxy? sys-net? sys-firewall? TemplateVMs?

https://github.com/QubesOS/qubes-doc/pull/603/files#diff-50cf93c6cf4fa87fc6b6612d706874a1
may be useful, but possibly also in need of correction.

--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

[sysad.andes]

-------- Original message --------

From: "sysad.andes" <sysad...@gmail.com>

Date: 7/16/20 15:56 (GMT-05:00)

To: awokd <aw...@danwin1210.me>

Subject: Re: [qubes-users] Qubes in a corporate network behind HTTP proxy [R4.0.x]

-------- Original message --------

From: 'awokd' via qubes-users <qubes...@googlegroups.com>

Date: 7/16/20 15:34 (GMT-05:00)

To: qubes...@googlegroups.com

Subject: Re: [qubes-users] Qubes in a corporate network behind HTTP proxy [R4.0.x]

unman:
> On Wed, Jul 15, 2020 at 11:41:57PM -0700, pr0xy wrote:
>> On 2020-07-15 09:28, pr0xy wrote:

>>> proxy.example.com:8080
>>>
>>> In R4.0.x how and where would I set this proxy for the Qubes Updates
>>> Proxy? sys-net? sys-firewall? TemplateVMs?

https://github.com/QubesOS/qubes-doc/pull/603/files#diff-50cf93c6cf4fa87fc6b6612d706874a1
may be useful, but possibly also in need of correction.

--

Also, besides what's listed in all the docs, make sure you have qubes-input-proxy installed in whatever template is behind the VM you want to handle updates for your templates

[pr0xy]

unman:

> It would be helpful if you said in what way it does not seem to work.

I am unable to update TemplateVMs. Due to the proxy issue they cannot
access updates so I get an error like this:

fedora-30:
---
[user@fedora-30 ~]$ sudo dnf update
Fedora Modular 30 - x86_64 0.0 B/s | 0 B
06:00
Error: Failed to download metadata for repo 'fedora-modular': Cannot
prepare internal mirrorlist: Curl error (28): Timeout was reached for
https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-30&arch=x86_64
[Operation timed out after 30001 milliseconds with 0 out of 0 bytes
received]
---

debian-10:
---
user@debian-10:~$ sudo apt update
Err:1 https://deb.qubes-os.org/r4.0/vm buster InRelease

Reading from proxy failed - select (115: Operation now in progress)
[IP: 127.0.0.1 8082]
Err:2 https://deb.debian.org/debian buster InRelease

Reading from proxy failed - select (115: Operation now in progress)
[IP: 127.0.0.1 8082]
Err:3 https://deb.debian.org/debian-security buster/updates InRelease
Reading from proxy failed - select (115: Operation now in progress)
[IP: 127.0.0.1 8082]
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: Failed to fetch https://deb.debian.org/debian/dists/buster/InRelease
Reading from proxy failed - select (115: Operation now in progress) [IP:
127.0.0.1 8082]
W: Failed to fetch
https://deb.debian.org/debian-security/dists/buster/updates/InRelease
Reading from proxy failed - select (115: Operation now in progress) [IP:
127.0.0.1 8082]
W: Failed to fetch
https://deb.qubes-os.org/r4.0/vm/dists/buster/InRelease Reading from
proxy failed - select (115: Operation now in progress) [IP: 127.0.0.1
8082]
W: Some index files failed to download. They have been ignored, or old
ones used instead.
---

I found that I am able to update Dom0. It is using sys-firewall as
UpdateVM to download updates.
sys-firewall is based on fedora-30, and the Upstream proxy is set in
TinyProxy. This seems to work.

> Check in dom0, the contents of /etc/qubes-rpc/policy/qubes.UpdatesProxy

In /etc/qubes-rpc/policy/qubes.UpdatesProxy it shows sys-net is being
used for non-Whonix TemplateVMs:
---
# Default rule for all TemplateVMs - direct the connection to sys-net
$type:TemplateVM $default allow,target=sys-net

$anyvm $anyvm deny
---

> Check in a template if you are using sources with http:// or https:// - look in /etc/yum.repos.d or /etc/apt/sources.list as appropriate

The fedora-modular.repo has all the http:// lines commented out. Other
repo files also appear to be using https:// as well.
debian-10 is also using https:// in sources.list

> Confirm that you have DNS resolving in whichever qube is acting as proxy.

DNS appears to be working from both sys-net and sys-firewall qubes.
cat /etc/resolve.conf from sys-net shows the company DNS servers. I can
ping these from sys-firewall.

awokd:

> https://github.com/QubesOS/qubes-doc/pull/603/files#diff-50cf93c6cf4fa87fc6b6612d706874a1 may be useful, but possibly also in need of correction.

I remember when you made that writeup based on my original issue, but I
didn't see it in the current Qubes Docs. I had gone through my original
post and tried those settings again before posting here. Once we figure
out why my current R4.0.x isn't working that doc could be re-included on
the Qubes site.

sysad.andes:

> Also, besides what's listed in all the docs, make sure you have qubes-input-proxy installed in whatever template is behind the VM you want to handle updates for your templates

Is qubes-input-proxy the same as this?
https://github.com/QubesOS/qubes-app-linux-input-proxy
That seems to be a USB device proxy. Is that what you were referring to,
or is there something else?

[pr0xy]

I tried a few more things, but have not yet been successful to get the
TemplateVMs to update via the proxy.

As Dom0 will update, and it is working through sys-firewall (the system
default for Dom0 UpdateVM), I tried changing sys-net to sys-firewall in
qubes.UpdatesProxy. The result was the same. I could not update
TemplateVMs. I reverted that change.

I removed my changes to TinyProxy in /etc/tinyproxy.conf from the
fedora-30 template. Instead I made the changes to the Upstream proxy in
sys-net in /rw/config/rc.local as per the document draft linked by
@awokd
~~~
echo "Upstream 10.0.0.1:8080" >>
/etc/tinyproxy/tinyproxy-updates.conf
~~~
Instead of timing out, I immediately got [Proxy CONNECT aborted] errors
from Fedora templates when attempting to update. When I switch this back
to:
~~~
echo "Upstream 10.0.0.1:8080" >> /etc/tinyproxy/tinyproxy.conf
~~~
the updates still fail to connect, but they take several minutes to time
out with [Operation timed out after 30000 milliseconds with 0 out of 0
bytes received]

As I can update via Dom0, I downloaded a fresh copy of Fedora 32.
$ sudo qubes-dom0-update qubes-template-fedora-32

When attempting to update fedora-32 TemplateVM I still get this (with
Upstream proxy set in tinyproxy-updates.conf):
---
[user@fedora-32 ~]$ sudo dnf update
Fedora 32 openh264 (From Cisco) - x86_64 0.0 B/s | 0 B
00:02
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
[Proxy CONNECT aborted]
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
[Proxy CONNECT aborted]
Fedora Modular 32 - x86_64 0.0 B/s | 0 B
00:02
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
[Proxy CONNECT aborted]

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
[Proxy CONNECT aborted]
---

Or this (with Upstream proxy set in tinyproxy.conf)
---
[user@fedora-32 ~]$ sudo dnf update
Fedora 32 openh264 (From Cisco) - x86_64 0.0 B/s | 0 B
06:00
Errors during downloading metadata for repository
'fedora-cisco-openh264':
- Curl error (28): Timeout was reached for
https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64
[Operation timed out after 30000 milliseconds with 0 out of 0 bytes
received]
- Curl error (28): Timeout was reached for
https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64

[Operation timed out after 30001 milliseconds with 0 out of 0 bytes
received]

Error: Failed to download metadata for repo 'fedora-cisco-openh264':

Cannot prepare internal mirrorlist: Curl error (28): Timeout was reached
for

https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64

[Operation timed out after 30001 milliseconds with 0 out of 0 bytes
received]

Fedora Modular 32 - x86_64 0.0 B/s | 0 B
06:00
Errors during downloading metadata for repository 'fedora-modular':
- Curl error (28): Timeout was reached for
https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64

[Operation timed out after 30001 milliseconds with 0 out of 0 bytes
received]

- Curl error (28): Timeout was reached for
https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64
[Operation timed out after 30000 milliseconds with 0 out of 0 bytes
received]

Error: Failed to download metadata for repo 'fedora-modular': Cannot
prepare internal mirrorlist: Curl error (28): Timeout was reached for

https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64
[Operation timed out after 30000 milliseconds with 0 out of 0 bytes
received]
---

I hope this additional info might help to lead toward some more
suggestions...

[pr0xy]

SUCCESS!

I figured it out. I can download updates via my corporate proxy! The act
of writing everything out helped me to catch something.

I noticed that in @awokd's writeup you have this:

~~~
echo "Upstream 10.0.0.1:8080" >>
/etc/tinyproxy/tinyproxy-updates.conf
~~~

You were missing "http" in the Upstream line. This works:

~~~
echo "Upstream http 010.0.0.1:8080" >>
/etc/tinyproxy/tinyproxy-updates.conf
~~~

If you make this small change, the instructions on that old document are
working on a fresh, clean install of R4.0.3, behind a corporate HTTP
Squid proxy. You may want to consider resubmitting it for inclusion in
the Docs.

Thanks all for the assistance!