Re: [qubes-users] Why does VPN needs its own firewall VM?
On Mon, Jul 10, 2017 at 04:09:09PM -0400, Chris Laprise wrote: > On 07/10/2017 03:15 PM, yreb-qusw wrote: > > On 07/09/2017 11:56 PM, Chris Laprise wrote: > > 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 Really useful, thanks for the contribution! -- noor |_|O|_| |_|_|O| Noor Christensen |O|O|O| n...@fripost.org ~ 0x401DA1E0 -- 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/20170711082832.p5mc7affycafpxdd%40mail. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: [qubes-users] Why does VPN needs its own firewall VM?
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.
Re: [qubes-users] Why does VPN needs its own firewall VM?
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? 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 :) -- 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/ab79946c-4824-e813-22f9-9a5898815243%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Why does VPN needs its own firewall VM?
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 -- 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/ee9bfdd5-d36b-1fde-1396-8df628397030%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Why does VPN needs its own firewall VM?
On Sun, Jul 09, 2017 at 05:48:55PM -1000, 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? 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| n...@fripost.org ~ 0x401DA1E0 -- 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/20170710095258.3uvr5nij2wi4fpbl%40mail. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[qubes-users] Why does VPN needs its own firewall VM?
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? -- 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/32ed9bd4-533d-5291-3ae3-a5a8b91201fa%40riseup.net. For more options, visit https://groups.google.com/d/optout.
