On Tue, Mar 28, 2017 at 03:23:26PM -0700, Nemo wrote: > On Tuesday, March 28, 2017 at 12:27:52 PM UTC-4, Nemo wrote: > > I'm really having a lot of trouble getting consistent results with the > > updates proxy. I've managed to break it on Firewall as well, despite only > > removing and then re-adding qubes-updates-proxy (as far as I can tell). > > > > > > Could you please help me by listing the elements required for it to work? > > > > > > Eg > > > > > > * TemplateVM > > ** Firewall page > > *** Allow connections to Updates Proxy: checked > > > > > > * ProxyVM(can be VPN or Firewall) > > ** Firewall page > > *** Allow access to 10.137.255.254:8082 (or just all) > > ** Services page > > *** qubes-updates-proxy listed and checked > > *** yum-updates-proxy must not be listed > > ** Packages > > *** tinyproxy (tinyproxy.x86_64) must be installed > > ** CLI firewall rules > > *** Official VPN documentation rules are fine, other rules might cause > > problems > > > > > > * Net > > ** Must have internet access > > > > > > Is there anything else? > > > > > > On Mar 28, 2017 8:47 AM, "Chris Laprise" <tas...@openmailbox.org> wrote: > > On 03/28/2017 08:14 AM, Nemo wrote: > > > > > > Yes, I did follow the official documentation to create the proxy. > > > > > > > > The only thing I've borrowed from the Rudd-O version is having Firewall > > > > downstream from VPN, and setting the VPN's firewall settings to block > > > > all traffic except that on my VPN's port. > > > > > > > > Doing updates through the VPN would be perfect if possible. > > > > > > > > Adding qubes-updates-proxy service to Firewall-VPN (and installing > > > > tinyproxy via tinyproxy.x86_64) causes an immediate connection error > > > > from dnf. Is that caused by the firewall rules I've added to VPN? Are > > > > they necessary, given a setup via the official documentation? > > > > > > > > > > It depends on where the rules are set, but I think its probable the added > > rules are blocking updates. This type of setup, with downstream proxyVM > > handling the updates proxy, is working well for me. > > > > > > > > Keep in mind the firewall already has a config to prevent any output not > > initiated by the VPN client (i.e. OpenVPN, etc) so restricting by port > > number may not be adding anything to link security. > > > > Here are the `--verbose` results from `dnf upgrade` in two scenarios: > > Net < VPN < Firewall-VPN (fedora-24 and qubes-updates-proxy) < TemplateVM > > [user@fedora-24-minimal-sys ~]$ sudo dnf -v upgrade > cachedir: /var/cache/dnf > Loaded plugins: builddep, noroot, debuginfo-install, needs-restarting, > config-manager, copr, reposync, protected_packages, playground, download, > qubes-hooks, generate_completion_cache, Query > DNF version: 1.1.10 > Cannot download > 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f24&arch=x86_64': > Cannot prepare internal mirrorlist: Curl error (7): Couldn't connect to > server for > https://mirrors.fedoraproject.org/metalink?repo=updates-released-f24&arch=x86_64 > [Failed to connect to 10.137.255.254 port 8082: No route to host]. > Error: Failed to synchronize cache for repo 'updates' > > Net < VPN (fedora-24-minimal w/ tinyproxy and qubes-updates-proxy) < > Firewall-VPN < TemplateVM > > [user@fedora-24-minimal-sys ~]$ sudo dnf -v upgrade > cachedir: /var/cache/dnf > Loaded plugins: debuginfo-install, config-manager, reposync, > needs-restarting, download, copr, Query, noroot, qubes-hooks, > protected_packages, generate_completion_cache, playground, builddep > DNF version: 1.1.10 > Cannot download > 'https://mirrors.fedoraproject.org/metalink?repo=fedora-24&arch=x86_64': > Cannot prepare internal mirrorlist: Curl error (28): Timeout was reached for > https://mirrors.fedoraproject.org/metalink?repo=fedora-24&arch=x86_64 > [Connection timed out after 120002 milliseconds]. > Error: Failed to synchronize cache for repo 'fedora' >
Hi I think that it would be best to try to focus on one scenario, and get that working right, rather than thrashing about. So let's try the Net < VPN < Firewall-VPN (fedora-24 and qubes-updates-proxy) < TemplateVM scenario. I think you have said that this works right for normal qubes attached to the Firewall-VPN, and that the traffic all goes down the VPN tunnel. On Firewall-VPN, make sure that you have the qubes-update proxy running: 'systemctl status qubes-updates-proxy' should show "running" 'netstat -tlp' should show tinyproxy listening on port 8082 'iptables -L -nv -t nat' will show you the nat table: there should be a redirect rule in PR-QBS-SERVICES , taking traffic for destination 10.137.255.254 and sending it to dpt 8082. 'iptables -L -nv' will show you the filter table: you should see a rule in the INPUT chain allowing traffic to port 8082. If you append "-Z" to the iptables commands, this will zero the counters. That means that you should be able to troubleshoot the problem relatively easily. Connect a template to the Firewall-VPN, and no other qubes. Then attempt to update the template. Run the two iptables commands, and look at the counters - you should be able to see if you are blocking traffic anywhere, or if there is something wrong. Look at the man pages using 'man' for more information on these commands. hth 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/20170328233444.GC8943%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
