On 07/10/2017 03:15 PM, yreb-qusw wrote:
On 07/09/2017 11:56 PM, Chris Laprise wrote:
On 07/09/2017 11:48 PM, yreb-qusw wrote:
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?


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

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?

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

--

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

--
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/e7e60589-53af-f2f1-5a1f-a69bdce4a9f5%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to