Worked well for me using a debian-9 template & commit 4e96ca8, only trouble was that my VPN provider's configs used /etc/update-resolv-conf and failed silently when it was missing - so shipping it with qubes-tunnel and installing it by default may be helpful.
Hi Chris,
Good to see the update!
However I think that's a separate issue; what I'm referencing is these lines in my .ovpn config:
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
The VPN installer script will normally download this if it's missing - used to change the DNS server to the VPN-provided one.
The script is here: https://raw.githubusercontent.com/ProtonVPN/scripts/master/update-resolv-conf.sh
After adding it everything worked well.
"Master version"
I have this running in a proxy AppVM (Not in a template)
Using PIA VPN service
OpenDNS checks out OK
I just tried this version in 4.0 in the template. Some notes feedback:
1) When I tried changing the DNS to OpenDNS in my config file:
setenv vpn_dns '208.67.222.222 208.67.220.220'
I then went to:
http://welcome.opendns.com/
It failed and informed me I was not using OpenDNS.
2) The step 3. in the abbreviated instructions say to run:
/usr/lib/qubes/qtunnel-setup --config
However I had to run:
sudo /usr/lib/qubes/qtunnel-setup --config
I was able to get to the internet....I didn't do any further testing. If you want me to try some things more then happy to help...
Thanks again for the work.
V
V
instead of:
setenv vpn_dns '208.67.222.222 208.67.220.220'
worked.
Both http://welcome.opendns.com/ and https://www.dnsleaktest.com/ show that OpenDNS are being used.
I am more then happy to help test, I was planning to make the shift but my DNS wasn't working...all good now. Thanks for the help...
I'll move my sys-VPNs to this new project...I was just reluctant to make the move as my DNS was not showing correct. All good now!
Thanks again...if anything comes up I'll report back. If you want me to try something more then happy to help...
Thx
Sorry for the basic question but is there something I need to do to the fresh debian template after installation?
I am trying to eliminate all possible issues but to install OpenVPN to the debian template:
1) I simply allow access to TOR or a network to get OpneVPN
2) Type : sudo apt-get install openvpn
I am having the same issue with Fedora as well, could there be another reason for this not connecting?
I get the "Waiting for connection" message but I don't get the "Link is up"...
Thanks for any thoughts...
V
Worked great for me with Qubes 4.0 and Fedora 26.
I'm unclear on how to use sys-firewall now though. Should it be sys-net -> sys-firewall -> VPN -> App?
Thanks.
Yes I can update my templates
> 2)
> sudo apt-get install openvpn should have nothing to do with the later
> step of install the tasket scrip-let ..... (not the tunnel) just
> the VPN script on GitHub
I was just hoping to make sure I haven't missed a basic step. It is my understanding the stock Debian-9 template that comes with 4.0 does not have OpenVPN installed. "sudo apt-get install openvpn" is all thats needed? Is there additional commands to install any dependencies?
> 3)
> if you Not talking about the "tunnel" script just the VPN tasket
> script, why not leave the Template out of the equation and just
> install the script in a fresh App-ProxyVM that "allows networking"
> (proxy)
Whats strange is I had the "Tunnel" script working prior to my fresh 4.0 install. The "VPN Tasket" also worked but moved to the "Tunnel" prior to my fresh install.
I tried going back to the "App-ProxyVM" only(i.e. no template configuration) but it too didn't work....
>
> and just leave Tor out of the whole puzzle IMO
I'll try with out TOR to see if that changes anything...
Thanks,
V
(Morlan - I used to connect my VPN proxy via sys-net -> VPN -> AppVM when I had this running...I would defer to other more seasoned Q users but consider multiple VPNs configured for different IPs, TOR over VPN...my thought was VPN thru sys-firewall consumed resources and wasn't sure it provided additional security...I would be open to being corrected if that is wrong)
I can get my browser to connect in the ProxyVM only after I manually change /etc/resolv.conf to NordVPN DNS servers.
But nothing that uses the ProxyVM as a NetVM can access the internet in any way. Cannot ping 8.8.8.8. Can't do anything. Doesn't matter what I do to /etc/resolv.conf in the AppVM.
I've updating to 1.4beta4 and switched templates from debian-9 to fedora-28, but I'm getting the same error - also it seems like openvpn flag defaults changed, as it now returns an error for the up and down arguments
Specifically, it parses /usr/lib/qubes/qtunnel-connect up as 2 arguments instead of 1; putting the whole phrase in double quotes fixes this, which I see you did but for some reason the quotes seem to be removed when ExecStart runs, i.e. checking systemctl status qubes-tunnel shows the command without the quotes
Hi Chris,
thanks for your effort behind qubes-tunnel. I tried recent version and have similar issues. Namely I would like to reach clearnet from my VM which is behind ProxyVM. My VPN leads to company network (which can be reached without problems), what is useful for devices which are there, but there is no separate DNS for it.
'sudo journalctl -u qubes-tunnel' looks fine - no errors. ipables look like that:
Chain PR-QBS (1 references)
pkts bytes target prot opt in out source destination
78 5206 DNAT udp -- vif+ any anywhere 10.139.1.1 udp dpt:domain to:8.8.8.8
0 0 DNAT tcp -- vif+ any anywhere 10.139.1.1 tcp dpt:domain to:8.8.8.8
64 4338 DNAT udp -- vif+ any anywhere anywhere udp dpt:domain to:8.8.4.4
0 0 DNAT tcp -- vif+ any anywhere anywhere tcp dpt:domain to:8.8.4.4
/etc/resolv.conf:
nameserver 10.139.1.1
nameserver 10.139.1.2
BTW do you think it makes sense to move setup stuff and do that using salt? - I made some basic sls files with your setup now purely reproducing your instructions.
I ran: sudo journalctl -u qubes-tunnel
and I get:
Sep 05 10:17:48 VPN-Mid qtunnel-setup[1138]: Wed Sep 5 10:17:48 2018 All connections have been connect-retry-max (7) times unsuccessful, e
Sep 05 10:17:48 VPN-Mid qtunnel-setup[1138]: Wed Sep 5 10:17:48 2018 Exiting due to fatal error
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Main process exited, code=exited, status=1/FAILURE
Sep 05 10:17:48 VPN-Mid qtunnel-setup[1149]: STOP-ing network forwarding!
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Unit entered failed state.
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Failed with result 'exit-code'.
Some additional notes:
My connection works on other devices
My TOR is not connecting
I am able to get Internet access via non-VPN connection
I did update Dom0 and my templates but it worked shortly afterwards
Any ideas how to trouble shoot this?
Thanks for any help...
Everything has been working fine, however recently my VPN tunnel is failing?
I ran: sudo journalctl -u qubes-tunnel
and I get:
Sep 05 10:17:48 VPN-Mid qtunnel-setup[1138]: Wed Sep 5 10:17:48 2018 All connections have been connect-retry-max (7) times unsuccessful, e
Sep 05 10:17:48 VPN-Mid qtunnel-setup[1138]: Wed Sep 5 10:17:48 2018 Exiting due to fatal error
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Main process exited, code=exited, status=1/FAILURE
Sep 05 10:17:48 VPN-Mid qtunnel-setup[1149]: STOP-ing network forwarding!
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Unit entered failed state.
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Failed with result 'exit-code'.
Some additional notes:
My connection works on other devices
Wed Sep 5 17:23:39 2018 TLS Error: TLS handshake failed
Wed Sep 5 17:23:39 2018 SIGUSR1[soft,tls-error] received, process restarting
Wed Sep 5 17:23:39 2018 Restart pause, 5 second(s)
Wed Sep 5 17:23:44 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xx:port xxx
I have restarted the computer, I am using Qubes 4.0 and leveraging a Debian 9 template.
The other devices are using OpenVPN...
Any ideas?
John,
Not sure what " script in an appvm/qube instead of the "tunnel" version ?" is...I had tried to set up the "iptables and CLI scripts" https://www.qubes-os.org/doc/vpn/ but really struggled. I found the Tasket solution easier to set up for a relative novice in desperate need of VPN security. I am also able to setup a few configurations so I can use different destinations. Is this the version you are using?
I managed to confirm my VPN is spawning out in an attempt to connect but the TLS is still not working...I tried it on 3 different networks.
I know you can modify the DNS resolver by adding the following to the OpenVPN configuration:
setenv tunnel_dns '8.8.8.8'
But what would I add to "Specifying 'local'" in the OpenVPN configuration?
Thanks again for any help...
IIRC you only need to specify the IP address of a regular system
interface, which in this case is eth0. So do a 'sudo ip addr' and look
up the eth0 'inet' address and put 'local <address>' in the config.
There's a chance this might work.
- Unfortunately this didn't work, I entered the following:
local 10.137.5.3
I was also able to find the IP in the Qubes Manager as an FYI, however I also ran the command in a terminal.
If it doesn't work, and you know of no custom firewall rules or net
settings that you can check or remove, then I'd consider the following
possibilities:
1. Your VPN provider has changed their TLS certificate or other
connection parameters. In this case their special client software (e.g.
installed on other devices?) would automatically refresh the config
files while your Qubes config would remain stale and unable to complete
TLS verification of the remote.
Remedy for this is to download your provider's current openvpn configs
and put them in /rw/config/qtunnel (making sure that qtunnel.conf points
to a new config file).
- It doesn't look like my VPN changed their TLS cert, downloaded a new config file and tried again fresh.
2. Some residual network property of your VPN VM has triggered a bug
that prevents it from working correctly. Simple remedy would be to
create and setup a new proxyVM and use that instead.
- I built a new VPN template with a new AppVM, I get the notification pop up but no connection.
3. Unlikely: Interference from malware, possibly residing in sys-net.
- I built a new sys-net (by creating a new Qube, provide network access, attached my Network controller/wireless....not sure more is needed to setup a sys-net) but this didn't fix it.
Whats strange is that the connection is showing up as allowed in my firewall log, which makes me think everything is working with the Tasket solution. I did notice a strange connection to port 137 (NetBIOS) in my firewall which could be related or the cause. I also recently saw an ssh attempt from within Qubes.
Unfortunately I have been under constant attack and a target and the only solution I see is a fresh rebuild or new computer unless you have another idea?
Thanks again Chris and Qubes for what you are doing...
You said that Tor was running. When combining Tor with VPN, the VPN's
connection type should be TCP, not UDP. Did you check that?
I did check this...opened the connection to Any/Any but this didn't seem to be the issue. I also eliminated TOR for testing and connected directly to the sys-net(to also eliminate any sys-firewall potential issues)
Before you go through the trouble of a whole reinstall, you could try
setting your VPN VM to use Fedora 28 instead to see if it works. You can
also perform a reinstall of the Debian template.
I tried with fedora-28 but also had the same TLS connection error. I ran the tests in step 3 as suggested and recieved the following errors with both the Debian and Fedora setup:
Fri Sep 14 10:30:53 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Fri Sep 14 10:30:53 2018 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.08
Enter Auth Username: My user name
Enter Auth Password: **************
Fri Sep 14 10:32:34 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]208.167.254.76:1198
Fri Sep 14 10:32:34 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Sep 14 10:32:34 2018 UDP link local: (not bound)
Fri Sep 14 10:32:34 2018 UDP link remote: [AF_INET]208.x.x.x:port xx
Fri Sep 14 10:32:34 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:36 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:40 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:48 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:33:04 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:33:34 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Sep 14 10:33:34 2018 TLS Error: TLS handshake failed
Fri Sep 14 10:33:34 2018 SIGUSR1[soft,tls-error] received, process restarting
Fri Sep 14 10:33:34 2018 Restart pause, 5 second(s)
Definitely strange considering it was working great for a few months...the good news is the kill switch functionality with this solution worked.
Any insight with the errors I recieved? If not I think a reinstall is my best course...
Fri Sep 14 16:55:06 2018 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.08
Enter Auth Username: My username
Enter Auth Password: **********
Fri Sep 14 16:55:35 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]208.X.x.x ; port xx
Fri Sep 14 16:55:35 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Sep 14 16:55:35 2018 UDP link local: (not bound)
Fri Sep 14 16:55:35 2018 UDP link remote: [AF_INET]208.x.x.x: port xx
Fri Sep 14 16:56:36 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Sep 14 16:56:36 2018 TLS Error: TLS handshake failed
Fri Sep 14 16:56:36 2018 SIGUSR1[soft,tls-error] received, process restarting
Fri Sep 14 16:56:36 2018 Restart pause, 5 second(s)