On Tuesday, March 28, 2017 at 7:34:45 PM UTC-4, Unman wrote: > 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
Thanks unman I found your previous thread helpful: https://groups.google.com/forum/#!topic/qubes-users/lyaPQjb8Pxo I've done the following troubleshooting steps on the FirewallVM - ----------------------- iptables -L -nv -t nat *** confirms that PR-QBS-SERVICE redirects traffic to dport 8082 (the packets counter increments when I attempt `dnf upgrade`) *** Chain PR-QBS-SERVICES (1 references) pkts bytes target prot opt in out source destination 3 156 REDIRECT tcp -- vif+ * 0.0.0.0/0 10.137.255.254 tcp dpt:8082 ----------------------- netstat -plnt *** shows me tinyproxy listening on port 8082 *** Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:8082 0.0.0.0:* LISTEN 550/tinyproxy ----------------------- systemctl status qubes-updates-proxy *** shows the proxy running *** ● qubes-updates-proxy.service - Qubes updates proxy (tinyproxy) Loaded: loaded (/usr/lib/systemd/system/qubes-updates-proxy.service; enabled; Active: active (running) since Tue 2017-03-28 19:31:52 EDT; 21min ago Process: 522 ExecStartPre=/usr/lib/qubes/iptables-updates-proxy start (code=ex Main PID: 550 (tinyproxy) Tasks: 3 (limit: 512) CGroup: /system.slice/qubes-updates-proxy.service ├─550 /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates.conf ├─557 /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates.conf └─558 /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates.conf Mar 28 19:31:52 sys-firewall-vpn systemd[1]: Starting Qubes updates proxy (tinyp Mar 28 19:31:52 sys-firewall-vpn systemd[1]: Started Qubes updates proxy (tinypr -------------------------------------------------------------- To help me understand how qubes-updates-proxy is working, is this more or less accurate?: The proxy gives the TemplateVM's network connection permission to break through it's own firewall's "Deny All" setting, for the purpose of updates only. The proxy should be applied on a FirewallVM before hitting a VPN/NetVM. The FirewallVM will block all traffic, but proxy the repo request, which it receives via tinyproxy at 10.137.255.254:8082. The request will pass through the FirewallVM and arrive in the VPN/NetVM as a normal repo request. Is that right? ------------------------------------------ To (maybe?) confuse things further: I just realized that the TemplateVMs will not update via Firewall-VPN even if they are set to allow all traffic. Although they will still update via the Net < Firewall < TemplateVM chain either directly or through the proxy without issue. -- 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/2421f6c2-d0af-4d08-9919-0cc732ce57d7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
