Qubes in a corporate network behind HTTP proxy

629 views
Skip to first unread message

pr0xy

unread,
Nov 20, 2017, 5:01:45 AM11/20/17
to Qubes Users
Please help a somewhat noob who wants to use Qubes in the office.

I got the OK to try using Qubes R3.2 in my company network as a
workstation. They have a very restrictive proxy that forces all traffic
through an HTTP/HTTPS proxy like:

proxy.example.com:8080

How could I force all Qubes traffic to go through that proxy and that
port?

Would that be in sys-net, or a Firewall VM?

awokd

unread,
Nov 20, 2017, 1:08:50 PM11/20/17
to pr0xy, Qubes Users
Check https://www.qubes-os.org/doc/vpn/ . Ignore the parts about VPN setup
but you should be able to set up your proxy redirect in the Proxy VM. I'm
assuming local traffic like DNS lookups would not go through the proxy.

pr0xy

unread,
Nov 27, 2017, 12:40:56 AM11/27/17
to awokd, Qubes Users
Thanks. I have been reading up on the ProxyVM, which seems to be the way
I would do this, but I'm a bit confused as to where I would add these
proxy settings. I'm not familiar with manipulating IP tables, or writing
the sort of scripts on that page, but is that what I would need to set?

I wanted to stay away from setting the environment variables for
http_proxy, https_proxy, ftp_proxy and no_proxy in each VM. Ideally I
think I'd like to use a ProxyVM to proxify an entire AppVM, but the
documentation doesn't make it clear how I would attempt this.

awokd

unread,
Nov 27, 2017, 4:33:03 AM11/27/17
to pr0xy, Qubes Users
You're right, you'd need to manipulate IP tables. There is no built in way
to do it with just the Qubes UI.

See
https://stackoverflow.com/questions/10595575/iptables-configuration-for-transparent-proxy
for an example if you wanted to use the transparent proxy approach.
Sys-whonix is essentially a transparent proxy that forwards all traffic
through Tor.

Another option could be
https://www.qubes-os.org/doc/config/http-filtering-proxy/ . See also
https://theinvisiblethings.blogspot.de/2011/09/playing-with-qubes-networking-for-fun.html
.



pr0xy

unread,
Nov 29, 2017, 6:12:50 PM11/29/17
to awokd, Qubes Users
I know how to manipulate a torrc file to work through my proxy. That
works very well as I can just set HTTPProxy host[:port] and it goes.

In a ProxyVM I'm a bit lost. Would I be setting Firewall rules in the
VM, or adding a network connection and manipulating that? I'm not clear
where I would be manipulating the IP Tables.

Unman

unread,
Nov 29, 2017, 9:20:57 PM11/29/17
to pr0xy, awokd, Qubes Users
You say you want ALL traffic to go through the proxy, but I'm guessing
that there is a local DNS server on the network.
The first thing is to be clear about what services are to pass through
the proxy.
Then the simplest way to get what you want is to manipulate the rules on
sys-net.
If you look at the rules there you will see that traffic from
sys-firewall and below is subject to MASQUERADE in the nat table, and
everything originating from vif interfaces outbound is allowed in the
FORWARD chain.
So if you want to direct http traffic through the proxy just insert a
rule in the PREROUTING chain like this:
iptables -t nat -I PREROUTING -i vif+ -p tcp --dport 80 -j DNAT --to proxy.example.com:8080

You can set this in /rw/config/rc.local - remember to chmod that file.
Look at https://www.qubes-os.org/doc/firewall/

I hope this points you in the right direction.
Obviously this wont affect traffic originating from sys-net but then I
recommend having a restrictive OUTPUT on sys-net and sys-firewall.

unman




pr0xy

unread,
Nov 30, 2017, 5:36:10 PM11/30/17
to Unman, awokd, Qubes Users
Sorry, that statement about 'all' traffic was misleading. You're correct
that DNS is handled separately. I have that set on the network
connection of my sys-net. DNS appears to be properly passed to the
iptables of sys-net.

Thanks for that IPtable example. I don't think I would have figured that
out on my own. Specifically I need to pass HTTP, HTTPS and FTP through
the corporate proxies. I modified your example to this:

iptables -t nat -I PREROUTING -i vif+ -p tcp --dport 80:443 -j DNAT --to
proxy.example.com:8080
iptables -t nat -I PREROUTING -i vif+ -p tcp --dport 21 -j DNAT --to
proxy.example.com:10021

I placed that in the /rw/config/rc.local of sys-net and made it
executable. Rebooting the machine shows that it's persistent, and they
show up in the PREROUTING section when I check
iptables --table nat --list

Problem is that AppVMs connected to the sys-firewall > sys-net don't
seem to take advantage of those settings. For example, I can't use
Firefox to connect to internet sites without manually setting the proxy
in the browser. Likewise, TemplateVMs with the same routing can't
update.

Should I instead be making these iptables settings in a ProxyVM, and
connect like: AppVM/StandaloneVM/TemplateVM > ProxyVM > sys-firewall >
sys-net?



awokd

unread,
Dec 1, 2017, 5:29:33 AM12/1/17
to pr0xy, Unman, Qubes Users
On Thu, November 30, 2017 22:36, pr0xy wrote:

> Specifically I need to pass HTTP, HTTPS and FTP through
> the corporate proxies. I modified your example to this:
>
> iptables -t nat -I PREROUTING -i vif+ -p tcp --dport 80:443 -j DNAT --to
> proxy.example.com:8080
> iptables -t nat -I PREROUTING -i vif+ -p tcp --dport 21 -j DNAT --to
> proxy.example.com:10021
>
> I placed that in the /rw/config/rc.local of sys-net and made it
> executable. Rebooting the machine shows that it's persistent, and they
> show up in the PREROUTING section when I check
> iptables --table nat --list
>
> Problem is that AppVMs connected to the sys-firewall > sys-net don't
> seem to take advantage of those settings. For example, I can't use
> Firefox to connect to internet sites without manually setting the proxy
> in the browser. Likewise, TemplateVMs with the same routing can't
> update.

Might depend on how that corporate proxy is configured. For example, if it
requires authentication. How friendly/linux savvy are the people who admin
it?

> Should I instead be making these iptables settings in a ProxyVM, and
> connect like: AppVM/StandaloneVM/TemplateVM > ProxyVM > sys-firewall >
> sys-net?

This would be my approach for flexibility but either should work.


pr0xy

unread,
Dec 1, 2017, 5:35:24 AM12/1/17
to Unman, awokd, Qubes Users
I've been testing with a ProxyVM without networkmanager. I set the
IPtables in the same fashion, but am unable to get AppVMs or templates
to connect to the internet.

I also found that updating the sys-net VM template from Fedora 23 to
Fedora 26 gives me a new option in the NetworkManager applet. There's an
option for Proxy in there now. It will accept PAC scripts (JavaScript).
I tried various scripts in there, like:

function FindProxyForURL(url, host)
{
if (url.substring(0, 5) == "http:") {
return "PROXY proxy.example.com:8080";
}
else if (url.substring(0, 4) == "ftp:") {
return "PROXY proxy.example.com:10021";
}
else if (url.substring(0, 6) == "https:") {
return "PROXY proxy.example.com:8080";
}
else {
return "DIRECT";
}
}

That doesn't seem to have an affect on anything either.

pr0xy

unread,
Dec 1, 2017, 5:47:00 AM12/1/17
to awokd, Unman, Qubes Users
On 2017-12-01 10:30, awokd wrote:
> On Thu, November 30, 2017 22:36, pr0xy wrote:
>
>> Specifically I need to pass HTTP, HTTPS and FTP through
>> the corporate proxies. I modified your example to this:
>>
>> iptables -t nat -I PREROUTING -i vif+ -p tcp --dport 80:443 -j DNAT --to
>> proxy.example.com:8080
>> iptables -t nat -I PREROUTING -i vif+ -p tcp --dport 21 -j DNAT --to
>> proxy.example.com:10021
>>
>> I placed that in the /rw/config/rc.local of sys-net and made it
>> executable. Rebooting the machine shows that it's persistent, and they
>> show up in the PREROUTING section when I check
>> iptables --table nat --list
>>
>> Problem is that AppVMs connected to the sys-firewall > sys-net don't
>> seem to take advantage of those settings. For example, I can't use
>> Firefox to connect to internet sites without manually setting the proxy
>> in the browser. Likewise, TemplateVMs with the same routing can't
>> update.
>
> Might depend on how that corporate proxy is configured. For example, if it
> requires authentication. How friendly/linux savvy are the people who admin
> it?

I'm the first person to run anything non-Windows in this network, so
this is new territory. It's a Squid 3.3.8 proxy for HTTP and HTTPS. The
FTP proxy is something else. There are no usernames or passwords
required for the proxy.

They gave me all the settings and told me to work it out if I want to
use Qubes, so that's what I'm trying to do...

>> Should I instead be making these iptables settings in a ProxyVM, and
>> connect like: AppVM/StandaloneVM/TemplateVM > ProxyVM > sys-firewall >
>> sys-net?
>
> This would be my approach for flexibility but either should work.

All the documentation I'm seeing makes me think it should work as well.

I'm not looking into the option of setting environment variables on each
template to see if that might work. So far the only other option that
has worked is to manually set the proxy in each piece of software, in
each AppVM.

Marek Marczykowski-Górecki

unread,
Dec 2, 2017, 8:08:01 PM12/2/17
to pr0xy, awokd, Unman, Qubes Users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Above iptables example will not work in most cases - HTTP direct
connection and HTTP proxy connection have some differences. Client
application must be aware that http proxy is being used.

There are two options:
1. Setup ProxyVM with some application that will intercept all the
connections and wrap them into HTTP proxy connection. Tor can do that,
but as a side effect you'll get all your traffic through tor. You can
also setup some HTTP proxy in transparent mode (at least squid supports
that).

2. Configure each application, in each VM to use HTTP proxy.
This may sound laborious, but in fact it is not: you can
set http_proxy and https_proxy variables in your template(s) and all VMs
based on it automatically will pick it up. Just create
/etc/profile.d/proxy.sh and export appropriate variables from there.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJaHt2yAAoJENuP0xzK19csogEH/3MLAWIm1C6vqpX/iugoxLl6
4tk0x4KXKWsNNfR50ir/8INgLWWXrCxk9QbZXy010nC3Dp0TNso3ei6ae+fc25as
2aj36TOyDA8ztV5F0libiZFxDCWcfzskvW7GiC57JlOustCq2CTTkaz3p5eHyjp8
ITnnOKpA/Ji7MTloxPNedw8hzpyMxJQudqryd7DDribbTHozG/xtBTRR/ZhPaIjI
Z849e8uRj47xrPWyVyOtuP6KGy5Q79CYCk1qM3bCd9EKipYNwqUZGZsPkI3SAfhv
xiM5YfP7Frc/62H64Z0KiieP9M5XIys64OWzK+trfSCCOzYafJDtJvti4q02s0o=
=vfFi
-----END PGP SIGNATURE-----

pr0xy

unread,
Dec 8, 2017, 3:16:15 AM12/8/17
to Marek Marczykowski-Górecki, awokd, Unman, Qubes Users
THANKs Marek!

I may try a transparent proxy in a VM at some point, but for now I went
with your second suggestion and added this to /etc/profile.d/proxy.sh in
Fedora and /etc/environment in Debian templates:

export http_proxy=http://proxy.example.com:8080
export https_proxy=http://proxy.example.com:8080
export ftp_proxy=http://proxy.example.com:10021

It seems to work for most browsers and other apps that need a web
connection. No need to set the HTTP proxy in all my apps. That's a time
saver.

===============

How can I set this for the Qubes Updates Proxy?
System > Global settings > UpdateVM

I've tried adding these proxy rules to Fedora and basing my sys-firewall
and sys-net on that. Updating templates "Fail to synchronize cache for
repo 'updates'" when I try setting the UpdateVM and TemplateVM to
anything but sys-whonix.

pr0xy

unread,
Dec 18, 2017, 4:13:54 AM12/18/17
to Marek Marczykowski-Górecki, awokd, Unman, Qubes Users
I am still a bit stuck concerning the Qubes Update Proxy. Where would I
set the environment variables for my corporate proxy so that I could
update dom0, templates and VMs?

I see some documentation mentioning the updates proxy here:
https://www.qubes-os.org/doc/software-update-vm/
I have read the section about "Updates proxy" several times, but I am
not sure what I would change.


Tom Zander

unread,
Dec 19, 2017, 9:09:12 AM12/19/17
to qubes...@googlegroups.com, pr0xy
On Monday, 18 December 2017 10:13:48 CET pr0xy wrote:
> I am still a bit stuck concerning the Qubes Update Proxy. Where would I
> set the environment variables for my corporate proxy so that I could
> update dom0, templates and VMs?

You should add sys-net to your template VM if you want that since the proxy
that is in place today is to avoid your template VM from accessing the
intranet or internet outside of your own machine.

Then google on where the template operating system (Fedora or Debian etc)
sets proxies for doing the command-line update, the configuration is the same
as Fedora or Debian etc.
I don’t know fedora at all,
in archlinux you’ll have a file in /etc/pacman/ which sets the current proxy,
in debian you’ll likely have one in /etc/apt/

grep -R -i PROXY /etc/*

may be useful too.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/floweethehub

Unman

unread,
Dec 19, 2017, 10:33:55 AM12/19/17
to Tom Zander, qubes...@googlegroups.com, pr0xy
On Tue, Dec 19, 2017 at 03:09:05PM +0100, 'Tom Zander' via qubes-users wrote:
> On Monday, 18 December 2017 10:13:48 CET pr0xy wrote:
> > I am still a bit stuck concerning the Qubes Update Proxy. Where would I
> > set the environment variables for my corporate proxy so that I could
> > update dom0, templates and VMs?
>
> You should add sys-net to your template VM if you want that since the proxy
> that is in place today is to avoid your template VM from accessing the
> intranet or internet outside of your own machine.
>
> Then google on where the template operating system (Fedora or Debian etc)
> sets proxies for doing the command-line update, the configuration is the same
> as Fedora or Debian etc.
> I don’t know fedora at all,
> in archlinux you’ll have a file in /etc/pacman/ which sets the current proxy,
> in debian you’ll likely have one in /etc/apt/
>
> grep -R -i PROXY /etc/*
>
> may be useful too.

Tom

Ive suggested before that if you give this advice you should
clearly state the consequences.

op - please dont do this. sys-net will not enforce a firewall and it is
bad practice to expose your templates in this way.

i understand you chose not to use the iptables route.
If you want to combine the Qubes proxy with an external proxy on
your network you should be able to do this by editing the tinyproxy.conf
file. You will find this in /etc/tinyproxy.

Qubes uses tinyproxy for all the template updates. you can make
tinyproxy use an external proxy.
The change you need to make is:
upstream host:port

check the documentation at
https://tinyproxy.github.io

unman

cooloutac

unread,
Dec 19, 2017, 2:02:11 PM12/19/17
to qubes-users

I woiuld ask the it guys at your company how to do it from linux. Then I'd create a new template vm and also proxy vm if you'd like and do basically same thing.

https://www.qubes-os.org/doc/firewall/

cooloutac

unread,
Dec 19, 2017, 2:03:11 PM12/19/17
to qubes-users

or just do it in sys-net like Uman said, which is suspect anyways.

Tom Zander

unread,
Dec 19, 2017, 4:55:55 PM12/19/17
to qubes...@googlegroups.com
On Tuesday, 19 December 2017 16:33:49 CET Unman wrote:
> Tom
>
> Ive suggested before that if you give this advice you should
> clearly state the consequences.

Ok, no worries. Here you go:

The consequences is that the template, which has no personal or identifying
information, can be used to run apps that make outbound connections. Don’t
worrry! No inbound connections are possible.

In short;
* There is no possibility of loss of private data (since there is none).
* There is no possibility of a remote hacking attack (b/c no
listening services).
* There is no possibility of a hacker installing bad software in
your template (only you can do that).

Bottom line is that there is no additional risk when a user uses a corporate
firewall and a http proxy to allow him to download updates.

Unman, being paranoid is fine, but making users unable to update their system
unless they do it the very complicated way you approve of will not help
security.
We are dealing with people, lets keep that in mind.
Specifically, the result of being too strict on this is that they will end up
either not updating (and missing security updates) or maybe just giving up
and using the simple route of throwing security out the window and just
getting the job done.

Perfection is the enemy of good enough.


And since I’m being nasty today, lets focus on another illusion in this
email. You wrote;
> sys-net will not enforce a firewall

Basically true, sys-net indeed bypasses sys-firewall.
But you are mistaken if you think that sys-firewall adds security.
Sys-firewall adds the _option_ of allowing you to _manually_ add security.
IF you have the know-how on how to do so. Which most people don’t.
sys-firewall allows you to block remote hosts by IP-address, manually. And
optionally.

Making people believe that having sys-firewall makes them more secure is
selling an illusion of security, which is really bad for actual security
because it follows that people will believe they are magically secured.
In reality the configuration of the firewall is a highly specialized and low-
level task that most people without sys-admin-training will simply not do.

Security is not about following a rulebook, it is about people first and
foremost. Lets not lose focus of that, please.

--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

awokd

unread,
Dec 20, 2017, 7:42:37 AM12/20/17
to cooloutac, qubes-users
On Tue, December 19, 2017 7:03 pm, cooloutac wrote:

> or just do it in sys-net like Uman said, which is suspect anyways.

That tinyproxy option further upthread seemed the most straight-forward
way to accomplish it, if it works!



Unman

unread,
Dec 21, 2017, 1:02:27 PM12/21/17
to Tom Zander, qubes...@googlegroups.com
Tom,

I don't want to get involved in a personal spat but I think that your reply
is completely misleading. As op was a self confessed noob and it's
possible that other newcomers to Qubes might come across your post I
think it's important to correct some misconceptions.

First, people come to Qubes for all sorts of reasons. It's reasonable to
assume that they want some level of security and, perhaps, privacy. They
may really need those things.Given that, I dont think it's helpful to bandy
around words like "paranoid".

Second, your reply is completely misleading about the role of Templates
in 3.2.
Since templates can be customised by the user it is not true that they
cannot contain private data. It's a moot point to what extent Templates do
contain identifying material, even when not customised.
It isn't true that Templates CANT contain listening services, or services
that make outbound connections without user intervention. Debian
Templates will start some services on installation, for example, and
there are other "aids" that may initiate outbound connections without
the user's knowledge. There are circumstances where this could be
extremely undesirable.
If (e.g) you use a web browser in a Template there is every chance that a
hacker may install bad software without your knowledge.

Why does this matter? Because although the Template *may* not contain
private data, the AppVMs based on it will do. If the Template is
compromised then all the AppVMs that use it will be compromised. If you
are a new user with just one or two templates, then you risk
compromising all your AppVMs, even the ones you deem to be most
precious.

It's for this reason that Qubes limits what can be done in a Template by
using the qubes firewall. Notice that this doesn't need to be set up by a
new user: I think you misunderstand the position here. Qubes enforces
the necessary rules for them, restricting access for Templates to the
update proxy by default.
This helps protect against user error - for example, opening a browser in
Template by mistake, and using it to browse the web. It also helps to
train users NOT to use their Templates like other qubes.
At one time the proxy restricted access to what looked like Debian (or
fedora) repositories. I preferred this set-up and use it myself, but it
has been removed from the default config. It can be reinstated by
editing tinyproxy.conf.

So Qubes recognises the fundamental importance of Templates by providing
a mechanism to protect them to some extent. By connecting directly to
sys-net you remove that protection. This is misguided, particularly
because in almost every case, (and particularly in op's) it's
unnecessary, since there are ways of accessing the company proxy without
completely removing the default template protections.

I completely agree that security isn't about following a rule book. The
best way to help someone secure themselves is to provide tools and
enable them to learn how to use those tools. Qubes is one of those
tools, and having some understanding of the use of Templates, the qubes
firewall and the proxy mechanism is important, even if not necessary.

unman

Tom Zander

unread,
Dec 21, 2017, 2:06:42 PM12/21/17
to qubes...@googlegroups.com
Thanks for your mail!

I think we are getting to the core of our little discussion :-)


On Thursday, 21 December 2017 19:02:23 CET Unman wrote:
> Since templates can be customized by the user it is not true that they
> cannot contain private data.

They can contain private data, because they have harddrive space. So
technically speaking you are not wrong.
Do you have any reason to believe there is any incentive to store your
private data, your account info (password) etc in a template?

> It's a moot point to what extent Templates do
> contain identifying material, even when not customized.

The entire point of Qubes is compartmentalization, which means actively
choosing where you have your login data, your keys and your private
messages.
A security worry that assumes people will copy their darkest secrets in
inappropriate qubes is a bit... odd.
And that is exactly what you say when you argue placing material you want to
keep secret in a template is a moot point.

> It isn't true that Templates CANT contain listening services,

This is true only if you pick your words very specifically.
It is true that template can try to listen to someone out there.
But its pointless because the Qubes system doesn't allow anyone to connect
to your templates. There is no port forwarding to your templates. Just
connecting to sys-net will not make that magically happen.

Bottom line is that no hacker can connect to your services on your template.
And thus you can’t get remote hacked by doing nothing.

> or services
> that make outbound connections without user intervention. Debian
> Templates will start some services on installation, for example, and
> there are other "aids" that may initiate outbound connections without
> the user's knowledge. There are circumstances where this could be
> extremely undesirable.

Interesting to hear, you maintain the Debian RPM for Qubes, right?
Can you explain which services are started automatically and do outbound
connections in that template?
You seem sure, so please share that info.

> If (e.g) you use a web browser in a Template there is every chance that a
> hacker may install bad software without your knowledge.

I highly doubt that. If that were true most Ubuntu boxes would have been
turned into bots.

But more importantly, the advice to only run software to update your
template stands.
The template VM is started for updating your operating system, it is not for
playing a flash game or running Skype. This was always the advice.

> If the Template is compromised then all the AppVMs that use it
> will be compromised.

This thought is not false, but your thoughts of how a template can get
compromised are clearly unfounded.
As you have admitted multiple times; all these technical things that make
basic tasks more difficult are there only to protect the user from
user-mistakes.

To be clear, I can get on board with the idea that users should be
discouraged from *using* templates. User training you called it.


I think the two different schools of thought here are that you work with
rules a lot. Decide that users can't do X or Y or Z, and you solve the
problem.
This works in a company, this works for a certain set of users.

I come from a different background, after 17 years of doing open source I
learned that telling people what NOT to do will always lead to
disappointment. :-)

Finding more user friendly ways of telling people what is a better way to
solve a problem is the direction I'm leaning towards. Lead, not punish.

As a quick example; make templates have a config file that indicate which
software is the ‘updater-GUI’ and make the icon-updater use this info to
only show a limited set of start-menu-items for template VMs.
A second icon associated from a template would be
“create VM based on this...”.


My thinking is that we have to work *with* people, not against them. Provide
more useful options, don't take away ones you think are dangerous.

Tom Zander

unread,
Dec 21, 2017, 2:11:41 PM12/21/17
to qubes...@googlegroups.com, Unman
On Thursday, 21 December 2017 19:02:23 CET Unman wrote:
> This helps protect against user error - for example, opening a browser in
> Template by mistake, and using it to browse the web.

A separate thought occured to me,

if Qubes is worried about users misusing templates, I'd argue that free
sudo-access should be removed from templates so you benefit from standard
user protection. In other words, you'd need a privilege escalation to
compromise your template. While today the bar is much much lower.

Naturally, an AppVM based on a template would have to have full sudo access.

What do people think about this?

pr0xy

unread,
Dec 22, 2017, 1:57:30 AM12/22/17
to Unman, Tom Zander, qubes...@googlegroups.com, Marek Marczykowski-Górecki
I did try the iptables method you suggested, but like Marek said, the
applications weren't aware of the proxy and didn't use it. I would just
get failed connections without setting the proxy in each piece of
software in each AppVM. The environment variable setting seemed to work
better in the AppVMs.

I tested setting the upstream host:port in the tinyproxy.conf of
sys-firewall. That didn't seem to work as I couldn't get Template
updates to connect to look for updates. I also tested setting this same
method on sys-net, but with the same results.

I also asked around on IRC about this, and was told that the Qubes
Update Proxy could be adjusted from here:

/etc/systemd/system/multi-user.target.wants/qubes-updates-proxy.service

Wasn't sure how I could manipulate the proxy from there, but it does
point to tinyproxy at /etc/tinyproxy/tinyproxy-updates.conf
I tried adding the upstream host:port to that file on sys-firewall, but
the template updates still give me an "Error: Failed to synchronize
cache for repo 'updates'" The result was the same attempting the same
setting on sys-net.



Unman

unread,
Dec 27, 2017, 8:07:50 PM12/27/17
to pr0xy, Tom Zander, qubes...@googlegroups.com, Marek Marczykowski-Górecki
Its very difficult to troubleshoot this without knowing more about what
is happening at the proxy , and in the Qubes networking.

Those iptables rules work with squid as a transparent proxy without any
client configuration. But they dont work for you. Please make sure that
you therefore remove any trace of them from your system.

As setting the proxy in tinyproxy didn't work for you either make sure
you remove those entries too.

I suspect the best thing to try is to to edit the qubes proxy config
file in the template. In a Debian template its in /etc/apt/apt.conf.d and
in Fedora /etc/yum.conf.d or /etc/dnf/dnf.conf
(Sorry to be vague but i dont have a Qubes box to hand.)


Edit the file so that it points to your corporate proxy instead of the
10.137.255.254 host.
Then make sure that you add the corporate proxy IP and port to allowed
in the template firewall.
You should be able to use just the HTTPS proxy port for both HTTP and
https traffic from the template.

good luck

unman

pr0xy

unread,
Jan 12, 2018, 3:03:37 AM1/12/18
to Unman, Tom Zander, qubes...@googlegroups.com, Marek Marczykowski-Górecki
Thanks for following up on this Unman. I really appreciate it.

SUCCESS!

Changing the /etc/apt/apt.conf.d in Debian and the /etc/dnf/dnf.conf in
Fedora, AND allowing the proxy IP on the firewall of EACH TemplateVM
finally allows me to update them via the sys-firewall. That's a huge
speed improvement over sys-whonix.

Now I'm wondering if my failure to set firewall rules was the reason I
couldn't use your earlier IPtables examples. I might revisit that, but
for now this solution allows me to use Qubes somewhat normally behind
this corporate proxy.

awokd

unread,
Jan 12, 2018, 6:27:34 AM1/12/18
to pr0xy, Unman, Tom Zander, qubes...@googlegroups.com, "Marek Marczykowski-Górecki"
On Fri, January 12, 2018 8:03 am, pr0xy wrote:
>
>
> SUCCESS!
>
>
> Changing the /etc/apt/apt.conf.d in Debian and the /etc/dnf/dnf.conf in
> Fedora, AND allowing the proxy IP on the firewall of EACH TemplateVM
> finally allows me to update them via the sys-firewall. That's a huge speed
> improvement over sys-whonix.
>
> Now I'm wondering if my failure to set firewall rules was the reason I
> couldn't use your earlier IPtables examples. I might revisit that, but for
> now this solution allows me to use Qubes somewhat normally behind this
> corporate proxy.

Glad to hear it! Sorry I couldn't help more. Would you mind providing a
detailed list of steps you had to do to get this set up behind a corporate
proxy? I know I'm a bit lost and it might help others in the future.

pr0xy

unread,
Jan 14, 2018, 9:15:05 PM1/14/18
to aw...@danwin1210.me, Unman, Tom Zander, qubes...@googlegroups.com, Marek Marczykowski-Górecki
Thanks for jumping in with some ideas anyway awokd.

The company is using a Squid transparent proxy for HTTP/HTTPS and
another proxy for FTP (which I haven't completely figured out yet). The
proxies are:

HTTP PROXY http://proxy.example.com:8080
HTTPS PROXY http://proxy.example.com:8080
FTP PROXY http://proxy.example.com:10021

Step 1: Whonix

Set the torrc so that Whonix can connect thru the proxy. Go to
sys-whonix | Tor User Config and edit the torrc file to add these lines:

DisableNetwork 0
HTTPproxy 10.0.0.1:8080
HTTPSproxy 10.0.0.1:8080
FascistFirewall 1

It's important here to use the IP address instead of the proxy name.
I've confirmed this on the Whonix forums.

Step 2: Set TemplateVM apps to use proxy

As Marek stated above, you can set http_proxy and https_proxy variables
in your template(s) and all app VMs based on them automatically will
pick it up. Just create
/etc/profile.d/proxy.sh and export appropriate variables from there.

I added the following to
/etc/profile.d/proxy.sh
in Fedora and
/etc/environment
in Debian templates:

export http_proxy=http://proxy.example.com:8080
export https_proxy=http://proxy.example.com:8080
export ftp_proxy=http://proxy.example.com:10021
export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
export FTP_PROXY=http://proxy.example.com:10021

Here I used the fully qualified domain names instead of the proxy IP.

Step 3: Allow Qubes TemplateVMs to update via sys-firewall

Don't do this on the Whonix templates. They update thru sys-whonix.

Add the following to the bottom of
/etc/apt/apt.conf.d
in Debian, and
/etc/dnf/dnf.conf
in Fedora after
### QUBES END ###:

(ex.)
[user@fedora-26 ~]$ sudo gedit /etc/dnf/dnf.conf
.
.
### QUBES END ###
proxy=http://10.0.0.1:8080

Again, here I had to use the IP of the proxy. I tested with the fully
qualified name, and it didn't work.

Finally, allow the proxy IP on the firewall of EACH TemplateVM
From the Qubes Manager (R3.2) | Firewall rules
Address 10.0.0.1
Protocol "Any"

That's working for me. I will try further experimentation with IPtables
and a ProxyVM, as those seem like better solutions. However, in the
meantime I have a working Qubes system and can actually do some work
with it instead of messing around with settings...for now.

awokd

unread,
Feb 24, 2018, 7:27:04 AM2/24/18
to qubes...@googlegroups.com, pr0xy
I'm attempting to convert the above into a Qubes doc
(https://github.com/awokd/qubes-doc/blob/transproxy/configuration/transparent-proxy.md)
but don't have a Squid proxy to test against.

For anyone who does (or is familiar with how they work):
A) Does it look right?
B) In step 3, adding apt/dnf proxy settings to all AppVMs based on the
same template as the UpdateVM's seems a bit broad. Is there a way to
fine-tune it?
C) Any special R4.0 considerations?



awokd

unread,
Mar 1, 2018, 9:17:12 AM3/1/18
to aw...@danwin1210.me, qubes...@googlegroups.com, pr0xy
On Sat, February 24, 2018 12:26 pm, 'awokd' via qubes-users wrote:

> don't have a Squid proxy to test against.
>
> For anyone who does (or is familiar with how they work):
> A) Does it look right?
> B) In step 3, adding apt/dnf proxy settings to all AppVMs based on the
> same template as the UpdateVM's seems a bit broad. Is there a way to
> fine-tune it?
> C) Any special R4.0 considerations?

Submitted as https://github.com/QubesOS/qubes-doc/pull/603.


Zrubi

unread,
Mar 2, 2018, 4:29:28 AM3/2/18
to aw...@danwin1210.me, qubes...@googlegroups.com, pr0xy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/24/2018 01:26 PM, 'awokd' via qubes-users wrote:

> I'm attempting to convert the above into a Qubes doc
> (https://github.com/awokd/qubes-doc/blob/transproxy/configuration/tran
sparent-proxy.md)
>
>
but don't have a Squid proxy to test against.
>
> For anyone who does (or is familiar with how they work): A) Does it
> look right? B) In step 3, adding apt/dnf proxy settings to all
> AppVMs based on the same template as the UpdateVM's seems a bit
> broad. Is there a way to fine-tune it? C) Any special R4.0
> considerations?


Well the biggest issue that if you have a transparent proxy that means
you do not need any configuration about the proxy. That why it is
TRANSPARENT.

So it seems your corporate have normal proxies, not transparent ones.
So the title (and the usage of the term: "transparent proxy") is
misleading.

Beside from that it is a good collection of all the possible proxy
settings locations.

- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEw39Thm3rBIO+xeXXGjNaC1SPN2QFAlqZGWQACgkQGjNaC1SP
N2QDHA/+KDsuGTavjimlA3nd6W0Wh7zmV7G8E7SFrF/NaY4ntftREKew8wPART6b
Jq+nIkTBLGadVsjs0vyZA/6e442wT8fQ++yr+1oBcwlPK7fwUJ06n0qpS7ZPsrKG
SXorr/oORb3O04Ru1fMAruxx3NvB+lOkJVnCFyG6KVaPx6sAfhvjVI6D43dm9xIl
zBL9N537cU0o6EMw6JSMxVXu9+MvjD+vS4P/NOQC8rJj9I/t7j9GkbNI29RF+rAf
UAtOFzvFD/4kYiym4pf68O/SSi2BNOw/Y7X7MYC2MPo6W+jsgMmcaZOUzVdvxvcW
EaBj+floNKOxce/dwwMNLxEfRV+D8sQKzw4L0l/m9YcK8FdD0+gd5bby4xMY9f5e
0dTcDZ9dvbQ/64zv5KWyGLQ+/n48S19T/X2oOGMIKR8jTmnBhrd3Ft48Olhwe3Pn
8wDjxtbIK6B8Wdxl5rDYhjBGpsRlINzZr/e+hH+8H0bjWOJev6dgIwRzCKBaXLwM
8PVLxEQgweQWULX/be5LI3LILC10gqm6jXXpscvc6ZykjXiOHAsU5FfZ/bs120HP
N2sHPE7K/mbgElbqZ8WhT+UrmIcaTacKmD35P6fRrLSggrgOrZKG7XsrbUQdRwH4
tauugFJmi99/QiuodJSfrn0Nrqb7uZHWEvng6iHlGEjP7FgEyBc=
=4Qhq
-----END PGP SIGNATURE-----

awokd

unread,
Mar 2, 2018, 9:50:51 AM3/2/18
to Zrubi, aw...@danwin1210.me, qubes...@googlegroups.com, pr0xy
On Fri, March 2, 2018 9:29 am, Zrubi wrote:
>
> So it seems your corporate have normal proxies, not transparent ones.
> So the title (and the usage of the term: "transparent proxy") is
> misleading.

I caught that too after the email, the PR I submitted doesn't talk about
"transparent" any more.

> Beside from that it is a good collection of all the possible proxy
> settings locations.

Thanks for looking it over!


Reply all
Reply to author
Forward
0 new messages