Hello Qubes community!
I am trying to setup my multiple VPN qubes on 4.1 with fedora-34-minimal as the base. I was able to get NordVPN working but I am struggling to get ProtonVPN running.
I keep getting: cannot resolve host address: x.protonvpn.com name or service not known
Anyone have an idea?
Can you share the instructions you are following to set up ProtonVPN?
The domain x.protonvpn.com does not point to anything, which is why you are getting this error. But it is hard to say how you can fix it without further information
I have put X instead of the real one for simplicity. I have followed the information on the qubes-vpn-support. I am use to do that on qubes 4.0. I was able to do protonvpn on 4.0.
Bishop
Please, make it easy for us to help you by linking to the instructions you followed.
Can you solve other domain names in the VM?
try:
dig google.com
If it says that dig is not a recognized program, install the package bind-utils (temporarily in the AppVM itself) with sudo dnf install bind-utils and try again.
Paste the output here.
I followed the instruction here:
I am making progress. on the other VPN proxy VM, connection is done by IP address.
dig does not work on both VM but sudo sg qvpn “dig google.ca” work.
It seems that the user starting the VPN does not have the right to do name resolution.
Ok, thanks for the extra information, it is becoming more clear to me.
When do you get the error listed in your first message? Is it after you run some command? If so, which command is it?
This is very likely a firewall issue. Only the qvpn user can access the network based on the configuration. Are you sure that the vpn is started by the qvpn user?
I get the error in the log if I try to start the the service
systemctl start qubes-vpn-handler
or if I try to start manually the tunnel with
sudo openvpn --cd /rw/config/vpn --config vpn-client.conf --auth-user-pass userpassword.txt
There is nothing in the documentation to start the service as qvpn. And there is no qvpn user, only a group.
I have added the vpn-handler-egress service to the proxy vm and it works. Is there another way?
Bishop
Hi, I am experiencing the same problem @Bishop did.
On Qubes 4.1-rc1 I created a sys-vpn qube, based on fedora-34-minimal and qubes-tunnel.
When I start sys-vpn it cannot connect to my VPN provider. According to journalctl -u qubes-tunnel this is because:
sys-vpn-air qtunnel-setup[776]: 2021-10-23 05:28:03 RESOLVE: Cannot resolve host address: domain.ofmy.vpn.org:443
A workaround is to set the IP address of my VPN provider in /rw/config/qtunnel/qtunnel.conf
remote ipaddres 443
That said, I am not sure why sys-vpn is not resolving DNS. I installed openresolv package (it did not work) and my resolv.conf file state:
nameserver 10.139.1.1
nameserver 10.139.1.2
May be some package is missing in fedora-34-minimal? I tried to install bind-utils but it did not work.
Cheers.
Did you do the link testing suggested at the end of Step 2? That narrows
down the source of connection issues by testing before any
Qubes-vpn-support bits are enabled.
One thing you should try that’s suggested in the Troubleshooting notes
is to add ‘vpn-handler-egress’ to the Services of the VPN VM. This will
disable a set a firewall restrictions that are related only to traffic
originating from inside the VPN VM, so its not critical for protecting
data streams.
Hey @tasket are you using your own Qubes-vpn-support tool & setup in a Fedora-34 VM as the ProxyVM?
I’ve been having same issues with dns name resolution as the OP but these issues only exist in Fedora 34 VM’s and not in Fedora 33 ones. Also only exists if/when the Qubes-vpn-support is installed, it does not occur in the same VM if I fully remove it from the system (at which point I can connect to the vpn using standard openvpn commands as normal from the same Fedora 34 VM).
Your suggestion you just posted to enable vpn-handler-egress actually “fixes” this problem as you suggested, so that’s great! But this probably shouldn’t be necessary should it? The only difference between my two ProxyVM templates is that one is Fedora 33 and the other is Fedora 34, they’re both configured exactly the same way and the vpn-handler-egress is only required in 34.
Perhaps something needs to be adjusted in the firewall scripts to make it more compatible with 34+?
I know far too little about configuring firewall rules correctly in Linux to be of much help with that.
Regardless, it works with the egress rules gone with that and I appreciate this tool, makes setting up VPN much easier / faster than the standard guide, thanks!
Linking to User -> Tor -> VPN -> Internet - 4.1 broken?
I had the same problem with a VPN over Tor tunnel. There has been a bug, in which ARP rquests in direction to the VPN gateway have not been proxied properly by Qubes virtual network - see the github issue in above link. Workaround in above post as well.
Qubes developers have closed the issue, so I am wondering if this bug still exists?
(I yet need to setup a VPN qube again)
Also note, if you are using VPN over Tor, tasket/Qubes-vpn-support might harm anonymity because of IP forwarding being used - see linked Whonix maintainer’s statement.
Is there any solution to this issue? I have the same errors each time with @tasket Qubes-vpn-support and @adw set up a proxyvm script
If I test the tunnel manually it works, but on restarting the proxy-vm I get continuous “RESOLVE: Cannot resolve host address: sfs.sdfsd.fds” this issue occurs using either script in fedora 34 and Debian 11. The VM will then most often fail to shutdown even after multiple attempts and has to be killed, very occasionally after restarting the proxy-vm it will connect although briefly and will return to not being able to resolve the host address.
Same here after upgrading to 4.1.
Apr 01 23:31:21 sys-vpn openvpn[775]: Initialization Sequence Completed
Apr 01 23:31:24 sys-vpn openvpn[775]: read UDP [EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH]: No route to host (code=113)
Apr 01 23:31:29 sys-vpn openvpn[775]: read UDP [EHOSTUNREACH|EHOSTUNREACH]: No route to host (code=113)
Apr 01 23:31:37 sys-vpn openvpn[775]: read UDP [EHOSTUNREACH|EHOSTUNREACH]: No route to host (code=113)
Some kind of mismatch between fedora-34 and fedora-34-minimal. For now i switch back to fedora-34 which works fine.
After some testing, i made R4.1 work with fedora-34-minimal Template and sys-firewall-mirage FirewallVM: