Why does VPN needs its own firewall VM?

[yreb-qusw]

at the end of the VPN CLI setup it says :

==
If you want to be able to use the Qubes firewall, create a new
FirewallVM (as a ProxyVM) and set it to use the VPN VM as its NetVM.
Then, configure AppVMs to use your new FirewallVM as their NetVM.
==

is there some reason why I should or should not just use the existing
firewall, or should each of the VPN VMs each have it's own firewall VM
for some reason?

[Noor Christensen]

You can use this firewall to manage a policy of what should be allowed
through the VPN, and what should be blocked. To do this, you need the
firewall to be in front of the VPN, since the traffic after VPN will be
encrypted.

Additionally, if you want to use a non-VPN NetVM for any other AppVMs
while the VPN is active you probably don't that traffic to be mixed with
the VPN traffic. Especially not if that firewall is in front of the VPN
(unencrypted).

-- noor

|_|O|_|
|_|_|O| Noor Christensen
|O|O|O| no...@fripost.org ~ 0x401DA1E0

[Chris Laprise]

Qubes firewall creates DNS accept rules that target only the upstream
netVM. This has no side-effect until you start whitelisting in the
presence of a tunnel; then DNS queries become blocked by the "Deny
except" rule even if "Allow DNS" is selected.

One workaround is to use a firewall VM between the VPN VM and downstream
VMs, as suggested in doc. You need one for each VPN VM where you intend
to whitelist.

The existing sys-firewall normally interfaces to sys-net; In that
configuration it can't filter any traffic that gets routed through the
tunnel. But you can re-assign it to use a VPN VM instead of sys-net; The
only downside is if you have any VMs that need direct non-VPN access to
the net, in which case its still good to keep sys-firewall connected to
sys-net and use other proxyVMs as VPN firewalls.

-

A different workaround is to use 'sed' to update iptables with the
correct DNS entries, as in this script which can replace
"qubes-vpn-handler.sh":

https://github.com/tasket/Qubes-vpn-support/blob/new-1/rw/config/vpn/qubes-vpn-ns

...then add this to the end of "qubes-firewall-user-script":

/rw/config/vpn/qubes-vpn-ns fwupdate

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[yreb-qusw]

Thanks, and if I DONT intend to white list anything, then is there any
reason to use the separate fw-VPNs for each VPN VM?

As, I think this white listing fw stuff has always been 'over my head'
.....

And I use suspend function daily, and it's a bit hassle to get the VPNs
up and running again, even with the launcher workaround, very often I
must use the launcher rc.local multiple times , and ping to see if it
works, and quite often they don't restart properly

So, unless there is a great reason , in my case, to do the extra
separate VPN fw VMs , I'd rather skip it :)

[Chris Laprise]

No reason to use separate fw-VPNs in that case.

>
> As, I think this white listing fw stuff has always been 'over my head'
> .....
>
> And I use suspend function daily, and it's a bit hassle to get the VPNs
> up and running again, even with the launcher workaround, very often I
> must use the launcher rc.local multiple times , and ping to see if it
> works, and quite often they don't restart properly

This has become a problem with newer openvpn versions: It appears to
give up due to an internal error instead of reconnecting.

My VPN support project solves this by setting up a systemd service for
the VPN; this forces openvpn to restart after it exits. It also makes it
more manageable via systemctl start/stop/restart/status etc...

https://github.com/tasket/Qubes-vpn-support

[Noor Christensen]

Really useful, thanks for the contribution!