On Tuesday, March 28, 2017 at 8:07:30 PM UTC-4, Nemo wrote:
> 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" <[email protected]> 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.
Hmmm, actually I missed running `iptables -L -nv`
[user@sys-firewall-vpn ~]$ sudo iptables -L -nv
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP udp -- vif+ * 0.0.0.0/0 0.0.0.0/0
udp dpt:68
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
ctstate RELATED,ESTABLISHED
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0
reject-with icmp-host-prohibited
Seems I'm filtering all this traffic, which would cause problems...
I tried recreating Firewall-VPN from scratch, and ran `iptables -L -nv`
immediately after adding qubes-updates-proxy
[user@sys-firewall-vpn2 ~]$ sudo iptables -L -nv
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP udp -- vif+ * 0.0.0.0/0 0.0.0.0/0
udp dpt:68
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
ctstate RELATED,ESTABLISHED
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
1 52 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0
reject-with icmp-host-prohibited
Doesn't seem like 8082 is automatically added. How can I add the record?
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/3aa42061-8108-447a-a9ac-7d6b4ede45fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
