Re: [qubes-users] handling DNS resolution when running comercial VPNs

70 views
Skip to first unread message
Message has been deleted

Chris Laprise

unread,
Aug 6, 2019, 11:09:27 AM8/6/19
to thecodingn...@gmail.com, qubes-users
On 8/6/19 10:42 AM, thecodingn...@gmail.com wrote:
> Hello,
>
> I have a commercial VPN that does not have any options to pass a DNS
> handling script. Following how i setup my qubes: sys-net <> sys-firewall
> <> VPN <> AppVm. As you see here I've setup a service vm named VPN where
> the VPN software is installed. I've also tried the other variation which
> is to have an additional firewall between VPN and AppVm. Neither setup
> works for browsing although the VPN is connecting as expected and AppVm
> can do IP pings (DNS ping for same address fails), but no web browsing
> is available which i suspect is due to no DNS handling setups. I have
> spent so much time trying to figure this out that I'm now left
> frustrated. Is there a way to do this DNS handling at system level
> rather than relying on VPN software to do that? If so, then how do i go
> about it?
>
> PS: Is there a difference between the two setups at all? what is the
> advantage of having an additional firewall between VPN and AppVm?
>
> OS: Qubes 4
> VPN Software: Proprietary based on openvpn

Hi,

There is a VPN guide in the doc section:

https://www.qubes-os.org/doc/vpn/

The CLI section is a very manual way to do it, but it shows how DNS
support is implemented in Qubes and provides some Qubes-specific
firewall protection. The Network Manager section can be useful if your
VPN provider has instructions for setting up the connection in NM.

A more automated and reliable way to setup VPNs is to use Qubes-vpn-support:

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

Most VPN services that are based on openvpn will offer downloadable
configuration files for openvpn. You can drop such config files into
Qubes-vpn-support and they should work.

OTOH, the 'proprietary' VPN apps are not a good fit for Qubes
networking. You can probably use them in each AppVM where you run your
browsers or other apps, but they won't handle DNS or firewall security
properly in a ProxyVM (the kind of 'provides network' VM you setup like
a firewall).

A separate firewall VM is not required as your ProxyVM will behave just
like a firewall in Qubes 4. This is assuming you trust the VPN software
not to be attacked/exploited in some way (and IMO this is a rather low
risk).

--

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

thecodingn...@gmail.com

unread,
Aug 6, 2019, 7:47:53 PM8/6/19
to qubes-users
So apparently the tasket repo does not work out of the box (obviously). Working through everything, now ran into an unfamiliar issue: pre-start firewall check fails with status 1. Looking at the code it seems the firewall rules are not there although firewall service is running actively. Executing the for loop in a standalone bash throws:
Fatal: can't open lock file /run/xtables.lock: Permission denied
The file is there, but i'm thinking this denial is purposeful and i prob should not sudo the loop execution. Any advice?

thecodingn...@gmail.com

unread,
Aug 6, 2019, 7:57:57 PM8/6/19
to qubes-users
Running ```sudo iptables -C FORWARD -o eth0 -j DROP``` throws an error itself: iptables: Bad rule (does matching rule exist in that chain?). So how can this ever run if running it directly in bash from inside the appvm does not work?

Chris Laprise

unread,
Aug 6, 2019, 9:45:51 PM8/6/19
to thecodingn...@gmail.com, qubes-users
On 8/6/19 7:57 PM, thecodingn...@gmail.com wrote:
> Running ```sudo iptables -C FORWARD -o eth0 -j DROP``` throws an error
> itself: iptables: Bad rule (does matching rule exist in that chain?). So
> how can this ever run if running it directly in bash from inside the
> appvm does not work?
>
> On Tuesday, August 6, 2019 at 7:47:53 PM UTC-4, thecodingn...@gmail.com
> wrote:
>
> So apparently the tasket repo does not work|out of the box
> (obviously). Working through everything, now ran into an unfamiliar
> issue: pre-start firewall check fails with status 1. Looking at the
> code it seems the firewall rules are not there although firewall
> service is running actively. Executing the for loop in a standalone
> bash throws:|
> |
> |
> Fatal:can't open lock file /run/xtables.lock: Permission denied
> |
> The file is there, but i'm thinking this denial is purposeful and i
> prob should not sudo the loop execution. Any advice?

FYI, the qubes lists discourage top-posting. Please reply at the bottom.

The firewall rules should be in
/rw/config/qubes-firewall.d/90_tunnel-restrict. If they're not, this may
indicate the setup steps were not followed through to completion (i.e.
if you installed to your template, but forgot step 4).

thecodingn...@gmail.com

unread,
Aug 7, 2019, 9:39:15 AM8/7/19
to qubes-users
you are right, but following exact instructions does not work as the following condition fails: ConditionPathExistsGlob=/var/run/qubes-service/vpn-handler* was not met

There's not such service to be found under /var/run/qubes-service and in qube settings dialog, there's no such service to add to the vm.

Chris Laprise

unread,
Aug 7, 2019, 9:45:51 AM8/7/19
to thecodingn...@gmail.com, qubes-users
Per step 1... "add vpn-handler-openvpn to the ProxyVM's Settings /
Services tab by typing it into the top line and clicking the plus icon."

You have to type it in first and click 'plus' icon.

thecodingn...@gmail.com

unread,
Aug 7, 2019, 11:23:03 AM8/7/19
to qubes-users
The proxy-firewall-restrict seems to get lost after each restart causing the --check-firewall to fail. I tried calling this script from rc.local directly and even tried adding it to the qubes-firewall-user-script, but neither solved the issue. I'd have to manually open terminal in vm and call the restrict using sudo, then restart the qubes-vpn-handler service using systemctl. Any solutions to this?

Chris Laprise

unread,
Aug 7, 2019, 3:16:27 PM8/7/19
to thecodingn...@gmail.com, qubes-users
This sounds like you ran 'install' in two different places, both the
template and the proxy vm; It should be only one. If that's the case,
you can try disabling the rc.local script.

Also, which Qubes template are you using?
Reply all
Reply to author
Forward
0 new messages