Yes.
Temporary failure in name resolution.
Thanks.
How about if you run the same command in the VPN VM?
Same output as the non-working VM. It doesn’t even show the PING sending packets line.
In the working VPN, it shows the sending line and hangs there for a bit, and then it shows a summary that says 100% packet loss. I tried it five times and it’s always complete packet loss. The last 2 times were after I loaded webpages in that same VM in Firefox ESR.
Should I put in some DNS server IPs?
Thanks.
How did you configure your VPN qube? Manually by installing openvpn? With network manager? A standalone VPN app?
Try the same command in the sys-firewall terminal (to confirm the problem is in the VPN configuration)
Hopefully someone else can chime in and give you more explicit suggestions for configuring your network.
To clarify, your setup is something like:
AppVM1 → vpnVM → sys-firewall → sys-net
AppVM2 → vpnVM → sys-firewall → sys-net
You are able to load browser pages in AppVM1 but with packet errors when you attempt to ping a domain name. But you can’t connect at all from AppVM2?
And attempts to ping a domain name from the vpnVM results in DNS errors?
1 Like
Yes, I have been calling them the working VM and non-working VM because in one I can browse the web and in the other I can’t.
It says “Temporary failure in name resolution.” very quickly after entering the command.
It seems that my vpnVM has sys-net under “Networking”.
It hangs and shows 100% packet loss.
New information is that I retried ping in the non-working VM and this time it doesn’t give “Temporary failure in name resolution.” quickly. Instead it hangs and gives 100% packet loss.
Using Qubes-vpn-support and vpn-handler-openvpn because I followed this tutorial.
Prior to this tutorial, I followed other methods for a VPN AppVM but could not get them to work. ProtonVPN seems more difficult to set up than others. Some of the methods used Fedora and network manager.
This tutorial for Debian 10 was the only one that worked enough that I could surf on the VPN. I thought it was only some trivial problem with my other AppVM that makes it not work too?
Thanks.
You should use sys-firewall, because it protects from DMA attacks See also: Firewalls & secure network configuration.
2 Likes
I’m not sure what is causing the problem. There are many variables in setting up a VPN in a VM. Have you tried the following guide?
I don’t think it would require that much modification to get ProtonVPN working. You can get the ProtonVPN config files here…
I would also like to echo @fsflover and say that your VPN VM should be connected to sys-firewall → sys-net… not directly to sys-net. sys-firewall will help make sure that any firewall rules in your VPN VM are properly applied and prevent memory attacks due to sys-net being connected to your network hardware.
Yes, I tried that guide you linked.
Sure, I will change it to sys-firewall. The tutorial I used, and others, said sys-net.
Thanks.
You can also try to simply install the ProtonVPN app in a VM that has “provides network” checked in the advanced tab of the settings. Configure the app with a kill switch, autostart, etc. See if you can get that running. If it works, you can limit yourself to certain servers and configure the VM firewall to only allow those IPs to connect.
Good luck!
Yeah, I might try it, but I spent so many hours just getting this to work 
And this way I can autoconnect.
My question here is not really how to get the VPN working, but what is different about my one non-working Qube. Isn’t there some way to output a whole lot of settings so I can compare the one Qube with the other?
Thanks!
Well… it doesn’t seem like it’s really working though. The app has an autoconnect setting.
Regarding your AppVM that doesn’t work… it might be due in part to something that isn’t configured properly in your VPN VM. The VPN VM wasn’t pinging properly when you tested it and even the “working VM” had problems.
I’m not aware of a generic output of all possible VM settings that would account for your network issues.
Sometimes it’s easier to just scrap what doesn’t work and start with a new VM from a clean template.
Or simply clone the working VM to get the second working one.
Yes, now I am more worried than I was at the start. But it seems like a problem with my entire system not the VPN VM? Since I have problems pinging from sys-firewall too.
His “working one” had problems too… though I suspect the problem is with his VPN configuration.
You had problems pinging from sys-firewall? Is it the default VM that was created during installation? Sounds like a bigger network problem.
Yes 
You suggested that try it earlier, and I get 100% packet loss. I have also tried ping from sys-net and get 100% packet loss.
I don’t remember the tutorials instructing any sys-firewall or sys-net changes.
That sounds like a local network problem. And yeah, sys-firewall → sys-net are generally “set it and forget it” type of VMs. You can create them from scratch, but they are more or less ready to use after installing Qubes.
Do you have another machine that you can use to test your local network? Are you wired or wireless? Lots of variables. Break it down and test everything. Good luck sorting this out.
Thanks.
I found that my sys-net and sys-firewall can ping other domains. I don’t know why it would have trouble with duckduckgo but it does. So it is only a VPN problem as you suspected before.
I found the app install to be the easiest for more than one VPN provider. Very fast. Just think of it like you are installing the app on a regular Linux machine. Get that going in a new AppVM and then tackle one of the more advanced guides to harden your network. Good luck…
2 Likes