Failing to configure Qubes-tunnel service VPN support

I have posted numerous times in the mailing list, forum, and started to think my issue was a bug so posted in in github (and then was told its a forum issue). I am at wits end trying to figure this out. I am “Linux literate” but far from a guru and I do not understand the inner workings of xen or Linux so understanding outputs of something like journalctl or other logs is beyond me. I know support is free so while beggars cant be choosers I don’t know what else to do than to flat out beg for help as I have tried everything I can think of and as far as i can tell its likely something i am doing wrong as at least one other person has given a “well it worked for me” type response.

  • I have tried using the qubes-tunnel contrib, and the previous method on the docs page.
  • I have tried on Qubes v4.0.3, v4.0.3rc1/2.
  • I have tried using debian/fedora/centos minimal as well as fedora 31 and 32.
  • I have tried using two different VPN providers, as well as pasting user names and passwords from the vpn providers clients into the qubes vpn setup (as well as typing them manually)
  • I have double checked the usenames and passwords.
  • and finally I have tried on my laptop and my desktop.

As it seems unlikely that there are problems with both computers, vpn providers, qubes versions tunnel/vpn methods etc I can again only guess that I am doing something wrong; though, I hav
e set this up on my laptop and desktop previously a few times for qubes 3x and for 4x (until 4.0.3) using either fedora minimal or centos minimal so I dont understand why now I am not able
to do it, especially as when using the docs vpn method I am able to successfully run
sudo openvpn --cd /rw/config/vpn --config openvpn-client.ovpn
before adding the scripts.

I will say, I was first turned onto Qubes by Whonix and how I could isolate VPN connections securely like in whonix for tor, there are of course other reasons i use Qubes but that is one of the top reasons so I really would like to get it working again. I have posted a snippet from the journalctl output here but am more than willing to post whatever other log needed to try and figure this out.

My latest attempt, using qubes-tunnel with a pia .ovpn file on a debian 10 minimal template… which is not working either. I am sincerely hoping the following will shed some light on the issue, and hoping even more that someone will understand and respond.

My latest series of attempts have consisted of:


root@sys-vpn:~# curl
curl: (6) Could not resolve host:

Then I tried pinging:

root@sys-vpn:~# ping
PING ( 56(84) bytes of data.
— ping statistics —
83 packets transmitted, 0 received, 100% packet loss, time 1059ms

and it just hung.

Then I tried the trouble shooting line:

root@sys-vpn:~# journalctl -u qubes-tunnel
– Logs begin at Mon 2021-02-08 15:02:31 EST, end at Mon 2021-02-08 15:14:01 EST. –
Feb 08 15:02:36 sys-vpn systemd[1]: Condition check resulted in Tunnel service for Qubes proxyVM being skip
lines 1-2/2 (END)

but not sure why the proxyvm is being skipped.

then I tried:

root@sys-vpn:~# sudo openvpn --config /rw/config/qtunnel/qtunnel.conf
Mon Feb 8 15:10:55 2021 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 20 2019
Mon Feb 8 15:10:55 2021 library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10
Enter Auth Username: XXXXXXX
Enter Auth Password: **********
Mon Feb 8 15:11:28 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]
Mon Feb 8 15:11:28 2021 UDP link local: (not bound)
Mon Feb 8 15:11:28 2021 UDP link remote: [AF_INET]
Mon Feb 8 15:11:28 2021 WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this
Mon Feb 8 15:11:28 2021 [newjersey409] Peer Connection Initiated with [AF_INET]
Mon Feb 8 15:11:29 2021 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Mon Feb 8 15:11:29 2021 OpenVPN ROUTE: failed to parse/resolve route for host/network: 2000::/3
Mon Feb 8 15:11:29 2021 TUN/TAP device tun0 opened
Mon Feb 8 15:11:29 2021 /sbin/ip link set dev tun0 up mtu 1500
Mon Feb 8 15:11:30 2021 /sbin/ip addr add dev tun0 broadcast
Mon Feb 8 15:11:30 2021 WARNING: OpenVPN was configured to add an IPv6 route over tun0. However, no IPv6 has been configured for this interface, therefore the route installation may fail or may not work as expected.
Mon Feb 8 15:11:30 2021 Initialization Sequence Completed

Please, I am obviously not capable fo figuring this out.

Are you using: GitHub - tasket/Qubes-vpn-support: VPN configuration in Qubes OS ?

The output from your openvpn command suggests that that’s working fine -
" Initialization Sequence Completed" is good.
So the problem likely lies in the way you have configured the proxy
iptables - obviously you dont have DNS working properly.
Open a connection and then run iptables -L -nv and iptables -t nat -L -nv
and post the results.

I also spent days to get my VPN working.
To make it simple this is my noob recommendation:

If Mullvad is not your preferred VPN you can at least get a working VPN setup for 4 weeks (for 5 €/$ Mullvad has no crazy subscription)

Alternatives, as already tested and linked below and here:

Previously I had used the one that the Qubes documentation pointed to Contents/ at master · Qubes-Community/Contents · GitHub, the “Set up a ProxyVM as a VPN gateway using iptables and CLI scripts” to be exact.

This time around, since it seems that using the GitHub - QubesOS-contrib/qubes-tunnel: Integration of vpn tunnels for Qubes OS / qtunnel method should (in theory for me) be the easiest I used that.

I had assumed that the iptables would be configured by the qubes tunnel contrib method, in the other method it gives a script to change the iptables. Regardless, here is the output i got Debian Pastezone

Thanks for the suggestion.
I am using pia at the moment, I had signed up for thier 2 year deal about a year ago so once that is up I will likely be switching and Mullvad does seem like a good option. I still cant figure though why pia worked before and would not be working now? I am hoping unman’s observation is able to shed some light on this.

Looking at the output you posted it looks like a mixed up set of rules.
In particular, there are rules that are set to stop communication from
within VPN VM to net, and these are not in place. Those rules should be
set when the qubes-tunnel* service is active.
Have you enabled the service and made it active?

When you restarted sys-vpn after initial configuration did you see any
popup? What did it say?

When i restart the sys-vpn i do not get any popups, honestly when I have sys-vpn set up as the networking vpn for another appvm - I for instance start an appvm and sys-vpn starts up as well with a “domain sys-vpn is starting”, thats it, no other messages.

I had assumed that the iptables and such would be set when I ran qubes-tunnel but maybe that is where I am messing up? I add the contrib repo to the template, then install qubes-tunnel in the template then close the template, create a sys-vpn with “provides networking” checked, open a sys-vpn terminal, and run /usr/lib/qubes/qtunnel-setup --config, put in my username/pwd, then copy one of the pia ovpn files to ```
/rw/config/qtunnel/qtunnel.conf then I had assumed that was it, is there perhaps something wrong in the steps I am taking?

Did you enable the qubes-tunnel-openvpn service in sys-vpn?

Well, I knew I was doing something wrong, not sure how i had the same brain fart every time at the same step, but in short no, I did not.

Unfortunately adding it to the sys-vpn, then restarting the sys-vpn did not seem to resolve the connection issue, appvms that i connect to it still time out.
I also tried just removing the sys-vpn and starting over with a new sys-vpn, this time adding the qubes-tunnel-openvpn service, then login/pwd, then cp the ovpn to qtunnel.conf but still not working.

Did you get any popup this time?

no pop-up.
Just in case I ran the iptable commands you mentioned and posted the results Debian Pastezone ; and took a look just to see if it was “exactly” the same and the output is a bit different though I cant say I understood what exactly the output was saying.
The difference as far as i could tell was there were a few more lines the first time as compared to the second time. These line were not present the second time:

Chain qbs-10-138-26-82 (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – * *
0 0 REJECT all – * * reject-with icmp-admin-prohibited

I also ran journalctl Debian Pastezone
I dont understand it really but lines that looked like that might be problematic were:

Feb 09 10:57:51 sys-vpn qubes-iptables[544]: iptables: Applying firewall rules: OK
Feb 09 10:57:51 sys-vpn qubes-iptables[544]: ip6tables: Applying firewall rules: OK
Feb 09 10:57:51 sys-vpn systemd[1]: Started Qubes base firewall settings.
Feb 09 10:57:51 sys-vpn systemd[1]: Condition check resulted in Qubes updates proxy (tinyproxy) being skipp


Feb 09 10:57:53 sys-vpn systemd[1]: Started Qubes network forwarding setup.
Feb 09 10:57:53 sys-vpn systemd[1]: Reached target Network.
Feb 09 10:57:53 sys-vpn systemd[1]: Condition check resulted in Tunnel service for Qubes proxyVM being skip
Feb 09 10:57:53 sys-vpn systemd[1]: Condition check resulted in Tinyproxy lightweight HTTP Proxy being skip

and maybe this?

Feb 09 10:57:53 sys-vpn systemd[1]: Reached target Login Prompts.
Feb 09 10:57:53 sys-vpn[761]: Could not change any device features
Feb 09 10:57:53 sys-vpn[761]: SIOCADDRT: File exists
Feb 09 10:57:53 sys-vpn[761]: SIOCADDRT: File exists

Also, as a just in case, I copied the .pem and .crt files over to the qtunnel dir, restarted, and nada no connection and no popups.

I just tried the qubes tunnel setup on a fresh install, made sure to enable the qubes-tunnel-openvpn service as well.
and still no sucess.

Thoughts. Please?

Qubes-community documentation for VPN with CLI scripts works well. You just have to follow it exactly. The main thing is that it can also fail open, so better to put rules for proxyvm firewall to only allow it connect with VPN servers only.
I haven’t used Qubes-tunnel ever but according to tasket himself, I think Qubes-vpn-support is better. Maybe fepitre may merge qubes-vpn-support in qubes contrib.

@wobo Thanks for the suggestion.
Actually I have tried both methods which is the only thing that makes me think it might not just be me (though likely is me) as I have used the VPN CLI version every time in the past (have probably set it up 3-4 times over the past two or three years… albeit not always smoothly).
I can certainly create a thread about trying to vpn cli method though.

Dear @system Mods.
It seems I am not able to change the subject in Discourse? I was going to change it to a more “qubes tunnel” specific subject and start a new “vpn cli specific” thread… though I feel like asides from wearing out my welcome I’m like spamming the forum to try to get support (though thats not my intention!!).

Well, I reinstalled 4.0.3 qubes on my laptop and tried with fed32min, using the vpn cli method. Not the solution I was hoping for but at least I have something working.