[Solved]
Dec 26, 2017, 09:04 PM
(This post was last modified: Dec 27, 2017, 01:12 AM by hinder90.
Edit Reason: typo, cut out some chit-chat
)
Dec 26, 2017, 09:04 PM
(This post was last modified: Dec 27, 2017, 01:12 AM by hinder90.
Edit Reason: typo, cut out some chit-chat
)
Hi,
First of all, thank you very much for your excellent guide (along with the thought updates) on how to set up a split-tunnel OpenVPN on Ubuntu 16.04. It was helpful, educational, and thorough- I have been working with Linux for nearly two decades and I hadn't even considered routing traffic in this manner. I am very excited to get the automation phase with a tool like Sick Rage... assuming I can get to that point.
Anyway, aside from all of the praise, I actually did have a very peculiar but serious problem that has pretty much put up a road block on me. After completing your step-by-step walkthrough I actually had what appeared to be fully operational split tunnel VPN with automatic kill switch. Had it not been for the fact that this is my third attempt at a ubiquitous VPN solution and that both of the other times that I gave up were because I was dogged with terrible network performance over the tunnel, I might not have even noticed that bandwidth was not only terrible, but the worst of all three approaches that I tried previously. Once I could test the network with the VPN up and down and could see that the kill switch was working as it should, I probably would have just gone and set up Transmission not realizing that the trickle of bandwidth was worse than a modem from 1995. I was so excited that everything seemed to function perfectly on the first try I didn't even want to know if it might be slow, but I thought better and installed Python and the trusty speedtest-cli tool and learned the ugly truth. The best performance I was going to see was around 3.8 MBit download and 3.6 Mbit upload. Considering that when unencumbered my internet link can be as fast as 299 Mbit download and 30 Mbit upload, this was a serious problem.
It wasn't until after trying about 5 different VPN vendors* that I even considered that the performance problems I was having were because there was something wrong with my setup, not because VPN provider offered terrible service- though in all likelihood they probably did anyway, since the best performance I ever saw using a proprietary VPN client on my Mac was about 50 or 60 Mbit download and, surprisingly, 29 Mbit upload, and usually I could expect half of that. My previous solutions was a second wireless ASUS which I was using as a VPN endpoint, running various firmwares and using a mixture VPN standards and encryption levels. I came try the split tunnel solution because the VPN vendors would have me believe that my Asus RT-AC86P router with dual 1 Ghz CPU was not sufficient to efficiently handle the encrypt/decrypt work like a computer could. Since I was only able to squeeze 25-30 Mbit download from it at best I decided to abandon that approach for something that involved an actually computer and software VPN client. I have a nice new QNAP NAS with a beefy Ubuntu 16.04 VM running on that should be perfect for the job. It has nearly free reign of a 4 core 2.1 GHz (3.4 burst) AMD R7 CPU which is designed to handle the encrypt/decrypt loads of transcoding, so it shouldn't even break a sweat for a VPN client. Sure enough, when I tested it, I couldn't even get the load of the VM to measure 0.10**.
The part about this that I really don't get is what I was getting for ping times. As soon as I connected on the tunnel, I was testing by pinging 8.8.8.8 and I was getting ping times consistently between 20 and 30 ms. However, when I got speedtest-cli going, the ping time for whatever test peer it picked, it was always miserably between 2100 and 2500 ms! When ping times are over a second, let along two, latency is beyond unusably bad. Also, to verify that the speedtest-cli results of 3-4 Mbit were actually valid, I tried to download a test file using wget and I was consistently getting no better than 200 KB download with any vendor, which is obviously even worse than the speedtest-cli result. I just couldn't figure out why Googles main DNS server 8.8.8.8 was giving great ping times while speedtest-cli's were awful. Other places were somewhere in the middle, usually between 100 and 200 ms.
To be clear, for each VPN provider I basically hacked their .ovpn file to incorporate the necessary parts of the example openvpn.conf that was in the guide. Since many VPN providers had a their own authentication typ cert, key, cipher, etc... I had to carefully customize each one, but in every case the results were always the same! I finally just gave up and thought I'd try asking for help. I am not sure if the writer of this guide answers questions here or not (no author credit is given on the guides) but I am hoping somebody might have a clue what is going on here. It's all pretty damned frustrating and after all of this effort I would hate to just give up on it.
I included the openvpn.conf for the provider I am presently in trials with. (IP Vanish). I also attatched /var/log/syslog from the days adventure but there is nothing in there that is damning except for when I screwed up the config once. I am not sure if any other files might be of use here, but if someone has an idea why this might be happening I would be joyful for that alone!
Thanks!
Matt
openvpn.conf:
client
dev tun
proto udp
remote sea-a22.ipvanish.com 443
resolv-retry infinite
nobind
persist-key
persist-tun
persist-remote-ip
ca /etc/openvpn/ca.ipvanish.com.crt
verify-x509-name sea-a22.ipvanish.com name
auth-user-pass /etc/openvpn/login.txt
comp-lzo
verb 3
auth SHA256
cipher AES-256-CBC
keysize 256
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-DSS-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-AES-256-CBC-SHA
disable-occ
script-security 2
route-noexec
#HTPC settings for split tunnel
up /etc/openvpn/iptables.sh
down /etc/openvpn/update-resolv-conf
* The only reason I went on the wild goose-chase with the VPN provider is that I think I might have gotten 30 Mbit download with one provider, but only at one location. (The problem with them was that my local peer, San Francisco, actually showed up in New Jersey, and no matter how many times the support person says "it's a problem with the ip database" the exhaustive ping test that speedtest-cli does confirms that the physical location is in fact in New Jersey. Since one of my requirement of the VPN provider is to be able to actually peer in those other countries and have the IP physically be hosted there, not somewhere else in the US. Therefore, I ditched them.)
** I concede that the load the hypervisor sees that matters, but the system is busy doing many assorted tasks usually running between 30 and 60% CPU overall. I can run a Windows VM on it and UI performs crisply so I am confident the hardware is more than up to the task.
First of all, thank you very much for your excellent guide (along with the thought updates) on how to set up a split-tunnel OpenVPN on Ubuntu 16.04. It was helpful, educational, and thorough- I have been working with Linux for nearly two decades and I hadn't even considered routing traffic in this manner. I am very excited to get the automation phase with a tool like Sick Rage... assuming I can get to that point.
Anyway, aside from all of the praise, I actually did have a very peculiar but serious problem that has pretty much put up a road block on me. After completing your step-by-step walkthrough I actually had what appeared to be fully operational split tunnel VPN with automatic kill switch. Had it not been for the fact that this is my third attempt at a ubiquitous VPN solution and that both of the other times that I gave up were because I was dogged with terrible network performance over the tunnel, I might not have even noticed that bandwidth was not only terrible, but the worst of all three approaches that I tried previously. Once I could test the network with the VPN up and down and could see that the kill switch was working as it should, I probably would have just gone and set up Transmission not realizing that the trickle of bandwidth was worse than a modem from 1995. I was so excited that everything seemed to function perfectly on the first try I didn't even want to know if it might be slow, but I thought better and installed Python and the trusty speedtest-cli tool and learned the ugly truth. The best performance I was going to see was around 3.8 MBit download and 3.6 Mbit upload. Considering that when unencumbered my internet link can be as fast as 299 Mbit download and 30 Mbit upload, this was a serious problem.
It wasn't until after trying about 5 different VPN vendors* that I even considered that the performance problems I was having were because there was something wrong with my setup, not because VPN provider offered terrible service- though in all likelihood they probably did anyway, since the best performance I ever saw using a proprietary VPN client on my Mac was about 50 or 60 Mbit download and, surprisingly, 29 Mbit upload, and usually I could expect half of that. My previous solutions was a second wireless ASUS which I was using as a VPN endpoint, running various firmwares and using a mixture VPN standards and encryption levels. I came try the split tunnel solution because the VPN vendors would have me believe that my Asus RT-AC86P router with dual 1 Ghz CPU was not sufficient to efficiently handle the encrypt/decrypt work like a computer could. Since I was only able to squeeze 25-30 Mbit download from it at best I decided to abandon that approach for something that involved an actually computer and software VPN client. I have a nice new QNAP NAS with a beefy Ubuntu 16.04 VM running on that should be perfect for the job. It has nearly free reign of a 4 core 2.1 GHz (3.4 burst) AMD R7 CPU which is designed to handle the encrypt/decrypt loads of transcoding, so it shouldn't even break a sweat for a VPN client. Sure enough, when I tested it, I couldn't even get the load of the VM to measure 0.10**.
The part about this that I really don't get is what I was getting for ping times. As soon as I connected on the tunnel, I was testing by pinging 8.8.8.8 and I was getting ping times consistently between 20 and 30 ms. However, when I got speedtest-cli going, the ping time for whatever test peer it picked, it was always miserably between 2100 and 2500 ms! When ping times are over a second, let along two, latency is beyond unusably bad. Also, to verify that the speedtest-cli results of 3-4 Mbit were actually valid, I tried to download a test file using wget and I was consistently getting no better than 200 KB download with any vendor, which is obviously even worse than the speedtest-cli result. I just couldn't figure out why Googles main DNS server 8.8.8.8 was giving great ping times while speedtest-cli's were awful. Other places were somewhere in the middle, usually between 100 and 200 ms.
To be clear, for each VPN provider I basically hacked their .ovpn file to incorporate the necessary parts of the example openvpn.conf that was in the guide. Since many VPN providers had a their own authentication typ cert, key, cipher, etc... I had to carefully customize each one, but in every case the results were always the same! I finally just gave up and thought I'd try asking for help. I am not sure if the writer of this guide answers questions here or not (no author credit is given on the guides) but I am hoping somebody might have a clue what is going on here. It's all pretty damned frustrating and after all of this effort I would hate to just give up on it.
I included the openvpn.conf for the provider I am presently in trials with. (IP Vanish). I also attatched /var/log/syslog from the days adventure but there is nothing in there that is damning except for when I screwed up the config once. I am not sure if any other files might be of use here, but if someone has an idea why this might be happening I would be joyful for that alone!
Thanks!
Matt
openvpn.conf:
client
dev tun
proto udp
remote sea-a22.ipvanish.com 443
resolv-retry infinite
nobind
persist-key
persist-tun
persist-remote-ip
ca /etc/openvpn/ca.ipvanish.com.crt
verify-x509-name sea-a22.ipvanish.com name
auth-user-pass /etc/openvpn/login.txt
comp-lzo
verb 3
auth SHA256
cipher AES-256-CBC
keysize 256
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-DSS-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-AES-256-CBC-SHA
disable-occ
script-security 2
route-noexec
#HTPC settings for split tunnel
up /etc/openvpn/iptables.sh
down /etc/openvpn/update-resolv-conf
* The only reason I went on the wild goose-chase with the VPN provider is that I think I might have gotten 30 Mbit download with one provider, but only at one location. (The problem with them was that my local peer, San Francisco, actually showed up in New Jersey, and no matter how many times the support person says "it's a problem with the ip database" the exhaustive ping test that speedtest-cli does confirms that the physical location is in fact in New Jersey. Since one of my requirement of the VPN provider is to be able to actually peer in those other countries and have the IP physically be hosted there, not somewhere else in the US. Therefore, I ditched them.)
** I concede that the load the hypervisor sees that matters, but the system is busy doing many assorted tasks usually running between 30 and 60% CPU overall. I can run a Windows VM on it and UI performs crisply so I am confident the hardware is more than up to the task.
![[-]](https://forum.htpcguides.com/images/htpc/collapse.gif "[-]")
