In Qubes 3.2 from any standard Debian AppVM connected to Sys-Net I am able to simply do from terminal:
sudo openvpn --config <VPN provider's ovpn config file>
..and it connects, and from then on all traffic from that AppVM is correctly routed through the VPN, as evidenced by testing IP address from web browser etc.
In Qubes 4, this does not seem to work. The same command from AppVM terminal works fine and reports successful connection to the VPN, but from that point all attempts to connect to any website or other remote host fail completely and just time out. As soon as I terminate the VPN by pressing ctrl-c from terminal, net connectivity resumes as normal.
What has changed in Qubes 4, and what do I need to do different to make it work?
Thanks for your reply. I'm entirely willing to consider using these better, more secure and effective methods in the long run. My first objective however is to determine why the simple method I used in Qubes 3.2 (running Openvpn from AppVM) does not successfully work the same way in Qubes 4.0.
> I would also try pinging known IP addresses (after connecting) to see if
> you can get a response. If you can, then the problem is likely with the
> DNS routing and dnat in the firewall.
I've just tested this. After connecting to the VPN from within the AppVM, I can successfully ping known IP addresses from the terminal. However attempts to connect to websites in the browser fail and time out.
What is my next step? How do I check or fix DNS routing and dnat in the firewall?
I'll give this a try, thanks. What mystifies me though is that I still have Qubes 3.2 installed on an older laptop and can confirm that on that version, none of these extra config steps are needed. I can activate and deactivate the VPN connection at will on the fly from an AppVM terminal, and it works flawlessly every time. Run openvpn and my IP address changes to the provider as expected. Hit ctrl-c to terminate the connection, and it goes back to my regular ISP-provided address as expected. Ideally I'd actually like to have this ability it switch it on and off as many times as desired during any given session, but maybe that's no longer possible in Qubes 4.
Also, I tried the instructions here:
https://github.com/tasket/Qubes-vpn-support/
..and they did not work. Everything seems to go okay, but after copying/installing/linking everything as directed and then shutting down and restarting the ProxyVM, it pops up the message "Ready to start link", and then just repeatedly does that every 10 seconds or so. The link never actually goes up. Problem isn't with the provider's .ovpn config file, since it works fine on Qubes 3.2 as well as another mainstream Linux distro, with no issues at all.
Not sure if it's significant, but the service "vpn-handler-openvpn" does not appear in the dropdown list of available services in the ProxyVM's settings screen, even though the template on which it is based (Debian 9) most definitely has Openvpn installed on it. I typed that service name in manually and it accepted it, but it also accepts any garbage text entered as well, so no idea whether it's actually functioning properly or not.
I was also admittedly a bit confused about whether I needed to separately install the qubes-tunnel package first, but the instructions didn't seem to explicitly require it so I did not. Other than that, I followed them to the letter but cannot get the link up.
So it seems. After spending several days trying to get a VPN connection up and working via every possible method conceivable, I have been met with complete and utter failure and have finally given up.
The results are always the same. Whether I connect manually with Openvpn, use qubes-vpn-support, qubes-tunnel, try from an AppVM, NetVM, ProxyVM, edit /etc/resolv.conf or any number of other files or scripts, it makes no difference. The VPN output reports successful connection (Initialization sequence completed) and I can ping any numerical IP address I specify without issue. But DNS resolution does not work, and nothing I try fixes it.
Booting up Qubes 3.2, the same VPN connection works flawlessly and DNS is trouble-free. So I've decided to solve my problem in the simplest (and only) way available: by going back to Qubes 3.2.
I appreciate all your attempts to help me with this. Thank you.
Examining both files and looking for the difference between the two, it appears the broken one did not ever invoke resolvconf include the following lines:
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
Adding those lines to the non-functioning file and running it resulted in success.
What files did you change? The config files?
Any specifics for a newbie would be appreciated and likely appreciated by others.
Thanks,
22Rip
In my case I had to change the config file supplied by the VPN provider itself, which ends with the extension ".ovpn"
In that file, just before the certificate info section which starts with:
<ca>
-----BEGIN CERTIFICATE-----
..I had to add the lines:
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
That change, in combination with the package 'resolvconf' being installed in the template that the AppVM is based on (Debian 9, which did not have it installed by default), caused the VPN connection to work properly with functioning DNS lookup.
When trying to connect to a VPN using openvpn from a Debian-9 AppVM within Qubes, I could connect but instantly lost DNS resolution which rendered the connection unusable.
Installing he package 'resolvconf' and adding the following lines to the .ovpn script supplied by the VPN provider:
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
...solved the issue and I was able to achieve full connectivity through the VPN.
Now, when trying to *disconnect* from that VPN using Ctrl-C from command line (or any other method) I am able to end the connection, but the DNS assignment does not appear to automatically reverse/undo and revert to the default
DNS servers provided by sys-net within Qubes, namely 10.139.1.1/2. And as a result I once again cannot connect to any websites due to lack of functioning DNS lookup.
Having done a bit of research I've tried using commands like:
sudo ifconfig tun0 down
sudo ip link delete tun0
..but in both cases I get a response that 'tun0 does not exist' or something similar.
Is there any extra step needed to completely drop the VPN connection and revert to using normal sys-net connectivity, without requiring a restart of the AppVM itself?
If I manually examine /etc/resolv.conf within the AppVM it still shows the default sys-net DNS entries as expected, so there must be some additional
command needed to fully end the connection and revert to normal.
What am I missing?
> https://www.qubes-os.org/doc/vpn/
>
> I believe it would be helpful if you indicate which method you have
> used to create the VPN per the URL there ....
>
>
> perhaps it is more obvious to others ....
Thanks for your reply - sorry I somehow missed seeing it earlier. I managed to sort of figure out what is going on and sort of fix it.
I am using the super-simple method of just invoking "openvpn whatever.ovpn" from terminal within an AppVM itself, rather than creating a dedicated proxy or gateway as suggested in the docs. What is happening is the following..
Initially before connecting to the vpn, the file /etc/resolv.conf contains the default Qubes sys-net dns entries, namely:
nameserver 10.139.1.1
nameserver 10.139.1.2
When the vpn connects, it uses update-resolv-conf to overwrite the contents of that file. It places some comment-text near the top and changes the nameserver entries to its own, which is good and wanted of course. No complaints.
When terminating the vpn connection by any means available (I tried several different ones), openvpn again automatically updates that /etc/resolv.conf file, but *only* to remove the entries it placed there, nothing more. The comment-text is left intact and the nameserver entries are simply deleted, resulting in a more or less empty and useless file and no DNS resolution whatsoever. The script does not seem to store and remember the previous entries that were there before (sys-net defaults) and replace them when finished. It just erases everything and leaves it like that.
Thus after disconnecting the vpn I have to go back into that file and manually re-add the sys-net entries to regain DNS resolution functionality. Ultimately I'm just going to write a short bash script that puts the needed entries back after disconnection, which I'll run at termination every time.
I don't know enough about openvpn to instruct it to "always run this extra script upon disconnection", though I'm sure there must be a relatively easy way to do so.
Thanks!!