Unable to uptade templates affer forced all traffic trhough VPN

[4lef7a+2cm...@guerrillamail.com]

Hi,

I've followed this tutorial in order to force all traffic to go through the VPN - https://www.qubes-os.org/doc/vpn/ .
While this was successful I'm no longer able to do any updates on the templateVMs (except the whonix which are working fine), it seems that the traffic somehow is now blocked.
Anyone knows what rule should be added to iptables in order to have this working through the VPN?
I've dropped all forward traffic (either upstream or downstream) from the sys-fw as suggested:

iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP

Should I need to allow the forwarding traffic to and from the subnet 10.137.1.0/24 in order to have the updates working again?

Thanks

----
Sent using GuerrillaMail.com
Block or report abuse: https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D

[Chris Laprise]

On 10/15/2016 08:07 AM, 4lef7a+2cmotzqtxu8g8 via qubes-users wrote:
> Hi,
>
> I've followed this tutorial in order to force all traffic to go through the VPN - https://www.qubes-os.org/doc/vpn/ .
> While this was successful I'm no longer able to do any updates on the templateVMs (except the whonix which are working fine), it seems that the traffic somehow is now blocked.
> Anyone knows what rule should be added to iptables in order to have this working through the VPN?
> I've dropped all forward traffic (either upstream or downstream) from the sys-fw as suggested:
>
> iptables -I FORWARD -o eth0 -j DROP
> iptables -I FORWARD -i eth0 -j DROP
>
> Should I need to allow the forwarding traffic to and from the subnet 10.137.1.0/24 in order to have the updates working again?
>
> Thanks

The Qubes update proxy runs in sys-net by default. Since it intercepts
requests, it has to be able to understand what the downstream VMs are
requesting. Encrypting traffic with a VPN client means the proxy in
sys-net can't update.

Workarounds:

1. Have the templates use sys-firewall instead

If privacy during updates is an issue for you...

2. Turn on the update proxy in the VPN VM (or a downstream proxyVM)...

https://www.qubes-os.org/doc/software-update-vm/#updates-proxy

3. If you have sys-whonix setup, it will already have a running update proxy

4. Reconfigure the templates to not use the update proxy


Chris

[4lgaqp+cqe...@guerrillamail.com]

Hi Chris,

Thanks for the suggestion.
Just to clarify, the VPN tunnel was created within the sys-firewall, and currently that's the only proxyVM that I'm using (apart from the sys-whonix), hence all traffic from the sys-net isn't encapsulated by the tunnel.
My understanding is that the sys-firewall merely forwards the traffic through the sys-net by adding a forwad rule in the sys-firewall every time a new VM is started. For that reason I was wondering if I cannot solve this more effectively by simple adding a forwarding rule in the sys-firewall to whitelist all traffic originated from 0.0.0.0/0 to the destination address 10.137.255.254/32 and port 8082, wouldn't this be possible?
Privacy during updates are not an issue for me, by the contrary, since this would allow more network throughput.
I confess I'm not very keen in changing templates or creating a dedicated proxyVm for this purpose.

[4lgpou+6fb...@guerrillamail.com]

Unfortunately I overlooked the config. There's already an automatic rule that whitelists all VMs that are marked to 'Allow connections to Updates proxy' to connect to the proxy on port 8082, therefore my suggestion would not work (specially given the fact that the rule to block all traffic is added at very top of the FORWARD chain).
So is there any way to use the same mechanism to use the proxy on the sys-net while forwarding the traffic to the sys-firewall?

[4li11b+ehe...@guerrillamail.com]

Ok, so I tried to enable the updates proxy in the sys-firewall consequently forcing all updates to go through the VPN, I followed the instructions outlined here - https://www.qubes-os.org/doc/software-update-vm/#updates-proxy
However, as soon as I try to run the updates on one of the vmtemplate I get the error "No route to host". All the templatevm has a default route to the sys-net (10.137.1.1), notwithstanding the update should be targeting the sys-firewall. Should I change the default GW of the templatevm ?!

Thanks

[Chris Laprise]

On 10/15/2016 12:56 PM, 4lgaqp+cqeepdnbinsts via qubes-users wrote:
> Hi Chris,
>
> Thanks for the suggestion.
> Just to clarify, the VPN tunnel was created within the sys-firewall, and currently that's the only proxyVM that I'm using (apart from the sys-whonix), hence all traffic from the sys-net isn't encapsulated by the tunnel.
> My understanding is that the sys-firewall merely forwards the traffic through the sys-net by adding a forwad rule in the sys-firewall every time a new VM is started. For that reason I was wondering if I cannot solve this more effectively by simple adding a forwarding rule in the sys-firewall to whitelist all traffic originated from 0.0.0.0/0 to the destination address 10.137.255.254/32 and port 8082, wouldn't this be possible?
> Privacy during updates are not an issue for me, by the contrary, since this would allow more network throughput.
> I confess I'm not very keen in changing templates or creating a dedicated proxyVm for this purpose.
>
> Thanks
>

I think you mentioned you were using the 'eth0 -j DROP' rules in
FORWARD.... that would imply that you /are/ putting all traffic through
the tunnel. Also, your thread title says you are doing this?

Unfortunately, making exceptions to a VM that is configured to stop all
plaintext forwarding can be a bit dicey. IOW, this kind of VPN VM is
supposed to be dedicated to the purpose.

Qubes' modular style of networking allows you to make exceptions with
low risk if you use (for example) a plain sys-firewall in parallel to a
VPN VM.

Chris

[4limaw+5vk...@guerrillamail.com]

I was finally able to put this to work! I have to set the sys-firewall as a qubes-yum-proxy forcing also all the apt/yum traffic through the tunnel.
Everything seems to be working fine now, although I do get a warning on the sys-firewall on the firewall settings while using the Qubes VM Manager:

"The 'sys-firewall' AppVM is not connected to a FirewallVM!

You may edit the 'sys-firewall' VM firewall rules, but these will not take any effect until you connect it to a working Firewall VM."

I would expect this warning to be normal, right? Is there any risk in terms of IP leakage to allow all the output traffic from the sys-firewall to the sys-net?

[johny...@sigaint.org]

> Ok, so I tried to enable the updates proxy in the sys-firewall
> consequently forcing all updates to go through the VPN, I followed the
> instructions outlined here -
> https://www.qubes-os.org/doc/software-update-vm/#updates-proxy
> However, as soon as I try to run the updates on one of the vmtemplate I
> get the error "No route to host". All the templatevm has a default route
> to the sys-net (10.137.1.1), notwithstanding the update should be
> targeting the sys-firewall. Should I change the default GW of the
> templatevm ?!

I found that using an UpdateVM other than sys-net results in failures
because the iptables rule to accept connections on local port 8082 is
never added to any VM, other than than the default NetVM.

Updates failed for me (packets to port 8082 being dropped on the update
VM) until I manually added the rule myself as the first filter rule:

"-A INPUT -i vif+ -p tcp -m tcp --dport 8082 -j ACCEPT"

Or you could just call /usr/lib/qubes/iptables-updates-proxy, which is
what happens in sys-net

[Manuel Amador (Rudd-O)]

On 10/15/2016 04:56 PM, 4lgaqp+cqeepdnbinsts via qubes-users wrote:
> Hi Chris,
>
> Thanks for the suggestion.
> Just to clarify, the VPN tunnel was created within the sys-firewall, and currently that's the only proxyVM that I'm using (apart from the sys-whonix), hence all traffic from the sys-net isn't encapsulated by the tunnel.

The instructions in the VPN doc (appear to me to) interfere with the Yum
Qubes proxy forwarding that is necessary for updates to work.

Try https://github.com/Rudd-O/qubes-vpn if possible, see if updates work
there. You must run the Qubes updates proxy service directly in the
same VPN VM. Note that update server queries will be handled by the
proxy and therefore will not go over the VPN.

> My understanding is that the sys-firewall merely forwards the traffic through the sys-net by adding a forwad rule in the sys-firewall every time a new VM is started. For that reason I was wondering if I cannot solve this more effectively by simple adding a forwarding rule in the sys-firewall to whitelist all traffic originated from 0.0.0.0/0 to the destination address 10.137.255.254/32 and port 8082, wouldn't this be possible?
> Privacy during updates are not an issue for me, by the contrary, since this would allow more network throughput.
> I confess I'm not very keen in changing templates or creating a dedicated proxyVm for this purpose.
>
> Thanks
>
>
>
>
>
> ----
> Sent using GuerrillaMail.com
> Block or report abuse: https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D
>
>

--
Rudd-O
http://rudd-o.com/

[Manuel Amador (Rudd-O)]

On 10/15/2016 04:56 PM, 4lgaqp+cqeepdnbinsts via qubes-users wrote:

> Hi Chris,
>
> Thanks for the suggestion.
> Just to clarify, the VPN tunnel was created within the sys-firewall,

I believe the VPN set up by the instructions in the official docs
interfere with the updates proxy functionality.

Try this: https://github.com/Rudd-O/qubes-vpn . Pay special attention
to README.md heading "Updates of template VMs attached to the VPN VM".
That ought to work.

--
Rudd-O
http://rudd-o.com/

[4lpt9o+3m1...@guerrillamail.com]

You don't need to manually add the iptables rules. When enable the 'qubes-yum-proxy' on the VPNVM the rule to iptables is automatically added:

Chain PR-QBS-SERVICES (1 references)
pkts bytes target prot opt in out source destination
0 0 REDIRECT tcp -- vif+ * 0.0.0.0/0 10.137.255.254 tcp dpt:8082

And also the corresponding rule on the INPUT chain:

Chain PR-QBS-SERVICES (1 references)
pkts bytes target prot opt in out source destination
0 0 REDIRECT tcp -- vif+ * 0.0.0.0/0 10.137.255.254 tcp dpt:8082

So you don't need to do this by hand.

@Manuel I agree with you, the instructions on the Qubes VPN doc. don't outline this step. And this is necessary to have the updates working while forcing all the traffic through the VPN.
Can someone add some references on the VPN article (https://www.qubes-os.org/doc/vpn/) in the same manner as this page reflected in this page - https://www.qubes-os.org/doc/software-update-vm/#updates-proxy . Since anyone following the VPN article,as it is, would not have the yum/apt updates working.

[4lpt9o+3m1...@guerrillamail.com]

On the second iptables rules I meant to past this instead:

0 0 ACCEPT tcp -- vif+ * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8082

Sorry for the confusion

[Chris Laprise]

On 10/16/2016 08:50 AM, 4lpt9o+3m11o9qubb38o via qubes-users wrote:
> You don't need to manually add the iptables rules. When enable the 'qubes-yum-proxy' on the VPNVM the rule to iptables is automatically added:
>
> Chain PR-QBS-SERVICES (1 references)
> pkts bytes target prot opt in out source destination
> 0 0 REDIRECT tcp -- vif+ * 0.0.0.0/0 10.137.255.254 tcp dpt:8082
>
>
> And also the corresponding rule on the INPUT chain:
>
> Chain PR-QBS-SERVICES (1 references)
> pkts bytes target prot opt in out source destination
> 0 0 REDIRECT tcp -- vif+ * 0.0.0.0/0 10.137.255.254 tcp dpt:8082
>
> So you don't need to do this by hand.
>
> @Manuel I agree with you, the instructions on the Qubes VPN doc. don't outline this step. And this is necessary to have the updates working while forcing all the traffic through the VPN.
> Can someone add some references on the VPN article (https://www.qubes-os.org/doc/vpn/) in the same manner as this page reflected in this page - https://www.qubes-os.org/doc/software-update-vm/#updates-proxy . Since anyone following the VPN article,as it is, would not have the yum/apt updates working.
>

Although following the doc would leave the updates working (user is
instructed to create a new VPN VM, not use existing sys-firewall) it
would be nice to be able to update over a VPN tunnel. I'll create an
issue for updating the doc.

Chris