Qubes: Unable to connect to VPN
Otto Kratik
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?
Chris Laprise
> I realize it's possible to create a dedicated ProxyVM and use NetworkConfig to route VPN traffic, but that's not what I'm asking about.
>
> 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.
leaking through to your regular ISP. There is also no failsafe to
prevent data leakage if openvpn for some reason decides to terminate.
>
> 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?
https://www.qubes-os.org/doc/vpn/
A better method is located here:
https://github.com/tasket/Qubes-vpn-support/
The difference is more failsafe checks and much smoother setup & operation.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Chris Laprise
to set the openvpn --verb level to 3 and look at the status messages.
That will show you what routing commands openvpn is issuing
(unfortunately it can vary a lot for different VPN services).
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.
Otto Kratik
> The Qubes VPN doc has two methods for correct openvpn configuration:
>
> https://www.qubes-os.org/doc/vpn/
>
> A better method is located here:
>
> https://github.com/tasket/Qubes-vpn-support/
>
> The difference is more failsafe checks and much smoother setup & operation.
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?
Chris Laprise
your VPN provider's DNS server (or other DNS server that you prefer)
instead of the Qubes internal routing addresses.
Replace this:
nameserver 10.139.1.1
nameserver 10.139.1.2
With this:
nameserver <your DNS server>
Hopefully that's all you'll need.
There are different ways to make this permanent. The best is probably to
install the "resolvconf" package (if not already there) and then tell
openvpn to use its update-resolv-conf script when you run it like this:
sudo openvpn --config link.conf --script-security 2 --up
/etc/openvpn/update-resolv-conf --down /etc/openvpn/update-resolv-conf
If your VPN provider sends DNS info via DHCP at connection time (most
do) the script will automatically send it to resolvconf.
If you want to use a different DNS server you can manually set
resolv.conf at connection time with your own script.
Chris Laprise
> It could be as simple as editing your /etc/resolv.conf so it contains
> your VPN provider's DNS server (or other DNS server that you prefer)
> instead of the Qubes internal routing addresses.
>
> Replace this:
> nameserver 10.139.1.1
> nameserver 10.139.1.2
>
> With this:
> nameserver <your DNS server>
_after_ the openvpn connection is started. Changing it before might
prevent openvpn from starting the connection.
Otto Kratik
> It could be as simple as editing your /etc/resolv.conf so it contains
> your VPN provider's DNS server (or other DNS server that you prefer)
> instead of the Qubes internal routing addresses.
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.
Chris Laprise
> On Monday, November 19, 2018 at 12:27:40 PM UTC-5, Chris Laprise wrote:
>> It could be as simple as editing your /etc/resolv.conf so it contains
>> your VPN provider's DNS server (or other DNS server that you prefer)
>> instead of the Qubes internal routing addresses.
>
> 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.
Qubes 3.x.
>
> 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.
correctly then click '+' and OK. You can go back to the list to make
sure it is there and checked.
Usually when "Ready to start" appears and there is no connection it
means there is an auth problem. The username or password may have been
mistyped, for instance. You can run 'sudo /usr/lib/qubes/qubes-vpn-setup
--config' to re-enter it.
To see what is happening check the log with 'sudo
/usr/lib/qubes/qubes-vpn-setup --config'.
>
> 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.
use one or the other.
Otto Kratik
> Qubes 4 networking is re-written and functions somewhat differently than
> Qubes 3.x.
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.
Otto Kratik
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.
22...@tutamail.com
What files did you change? The config files?
Any specifics for a newbie would be appreciated and likely appreciated by others.
Thanks,
22Rip
Otto Kratik
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.
22...@tutamail.com
Otto Kratik
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?
Jon deps
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 ....
Otto Kratik
> 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.
unman
If you check the man page, there are a variety of different options for
running scripts/commands at different events, but I suspect that will
fit the bill.
Otto Kratik
> Call it with --down <cmd> to have a script run when the tunnel closes.
> If you check the man page, there are a variety of different options for
> running scripts/commands at different events, but I suspect that will
> fit the bill.
Thanks!!