Re: [qubes-users] Qubes in a corporate network behind HTTP proxy [R4.0.x]
On 2020-07-17 06:55, pr0xy wrote: > On 2020-07-17 02:55, pr0xy wrote: >> On 2020-07-16 12:34, unman wrote: >>> 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. >> >> 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
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy [R4.0.x]
On 2020-07-17 02:55, pr0xy wrote: > On 2020-07-16 12:34, unman wrote: >> 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. > > 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: >>
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy [R4.0.x]
On 2020-07-16 12:34, unman wrote: > 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. 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
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy [R4.0.x]
Original message From: "sysad.andes" Date: 7/16/20 15:56 (GMT-05:00) To: awokd Subject: Re: [qubes-users] Qubes in a corporate network behind HTTP proxy [R4.0.x] Original message From: 'awokd' via qubes-users Date: 7/16/20 15:34 (GMT-05:00) To: qubes-users@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-50cf93c6cf4fa87fc6b6612d706874a1may 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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5f10b64e.1c69fb81.e7294.cf6b%40mx.google.com.
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. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f07c8424-0320-e649-8399-93c06406b6fb%40danwin1210.me.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy [R4.0.x]
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200716123452.GA22089%40thirdeyesecurity.org.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy [R4.0.x]
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. 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/30cadaa83ba9c35077ca2734898b4e1a%40riseup.net.
[qubes-users] Qubes in a corporate network behind HTTP proxy [R4.0.x]
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? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e3b58b5b86280b1723548d049bba4802%40riseup.net.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
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! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/511af2b5ee832180559f43874df5c545.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
-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- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/89477a12-a979-a273-a369-83ba2c8336d4%40zrubi.hu. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2300744b5da709c3d7ddbac97995b78a.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On Mon, January 15, 2018 2:15 am, pr0xy wrote: > 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. 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? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/db47e5a873760b3dc32a3c5e2e901ee4.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On 2018-01-12 11:27, awokd wrote: > 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. 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fa0a1856ce806e02e49bb9c47100b4f4%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b0bdd7093b4d7986f90b2434d589269c.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On 2017-12-28 01:07, Unman wrote: > On Thu, Dec 21, 2017 at 10:57:26PM -0800, pr0xy wrote: >> On 2017-12-19 15:33, Unman wrote: >> > 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 >> >> 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. >> >> > > 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 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On Thu, Dec 21, 2017 at 10:57:26PM -0800, pr0xy wrote: > On 2017-12-19 15:33, Unman wrote: > > 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 > > 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. > > 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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20171228010748.igkrp6w32emwpxen%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On 2017-12-19 15:33, Unman wrote: > 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 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e1213ec0cbfd74a27bb2ba34143bd0e2%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
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? -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4630734.vq5SLFKYRq%40strawberry. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
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 Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/40945027.Ov4JLljASd%40strawberry. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On Tue, Dec 19, 2017 at 10:55:46PM +0100, 'Tom Zander' via qubes-users wrote: > 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, 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 connectin
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2682772.EKl5eY0fiO%40strawberry. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20171219153349.vmkxn7epchvynfrm%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3673012.sFe5jTk4l6%40strawberry. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On 2017-12-08 08:16, pr0xy wrote: > On 2017-12-03 01:07, Marek Marczykowski-Górecki wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> On Fri, Dec 01, 2017 at 02:46:55AM -0800, pr0xy wrote: >>> 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. >> >> 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- > > 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. 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 doc
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On 2017-12-03 01:07, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Fri, Dec 01, 2017 at 02:46:55AM -0800, pr0xy wrote: >> 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. > > 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- 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Dec 01, 2017 at 02:46:55AM -0800, pr0xy wrote: > 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. 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- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20171203010752.GD1935%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/bc84b6ebf3f6d04aeb09afbe8639f3c2%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On 2017-11-30 22:36, pr0xy wrote: > On 2017-11-30 02:20, Unman wrote: >> On Wed, Nov 29, 2017 at 03:12:46PM -0800, pr0xy wrote: >>> On 2017-11-27 09:33, awokd wrote: >>> > On Mon, November 27, 2017 05:40, pr0xy wrote: >>> >> On 2017-11-20 18:08, awokd wrote: >>> >>> On Mon, November 20, 2017 10:01, pr0xy wrote: >>> 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? >>> >>> >>> >>> 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. >>> >> >>> >> 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. >>> > >>> > 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 >>> >>> 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. >> >> 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 > > 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: Ap
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e4e54fe8eaad517b4f44c1f3091763e6%40elude.in. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On 2017-11-30 02:20, Unman wrote: > On Wed, Nov 29, 2017 at 03:12:46PM -0800, pr0xy wrote: >> On 2017-11-27 09:33, awokd wrote: >> > On Mon, November 27, 2017 05:40, pr0xy wrote: >> >> On 2017-11-20 18:08, awokd wrote: >> >>> On Mon, November 20, 2017 10:01, pr0xy wrote: >> 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? >> >>> >> >>> 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. >> >> >> >> 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. >> > >> > 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 >> >> 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. > > 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 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? -- You received this message because you are subscribed to the Google Groups "qubes-users" group
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On Wed, Nov 29, 2017 at 03:12:46PM -0800, pr0xy wrote: > On 2017-11-27 09:33, awokd wrote: > > On Mon, November 27, 2017 05:40, pr0xy wrote: > >> On 2017-11-20 18:08, awokd wrote: > >>> On Mon, November 20, 2017 10:01, pr0xy wrote: > 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? > >>> > >>> 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. > >> > >> 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. > > > > 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 > > 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. 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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20171130022054.uql7ofsors5jen6f%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On 2017-11-27 09:33, awokd wrote: > On Mon, November 27, 2017 05:40, pr0xy wrote: >> On 2017-11-20 18:08, awokd wrote: >>> On Mon, November 20, 2017 10:01, pr0xy wrote: 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? >>> >>> 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. >> >> 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. > > 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 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a0d09ed0eda8239c50cd38fdf2c96338%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On Mon, November 27, 2017 05:40, pr0xy wrote: > On 2017-11-20 18:08, awokd wrote: >> On Mon, November 20, 2017 10:01, pr0xy wrote: >>> 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? >> >> 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. > > 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. 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 . -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2a119e4812ece7ea879234495b8f7a9d%40elude.in. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On 2017-11-20 18:08, awokd wrote: > On Mon, November 20, 2017 10:01, pr0xy wrote: >> 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? > > 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. 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7269b9d4d014924bcc3cfc8a4600e416%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy
On Mon, November 20, 2017 10:01, pr0xy wrote: > 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? 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1262784e42013589d71eb7028916a94a%40elude.in. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes in a corporate network behind HTTP proxy
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? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5d2788c287b252827a8a98f13cd393c6%40riseup.net. For more options, visit https://groups.google.com/d/optout.
