Leaderboard

Hello! We're very glad to announce all VPN servers progressive upgrade to Data Channel CHACHA20-POLY1305 cipher and TLS 1.3 support. UPDATE 18-Nov-2020: upgrade has been completed successfully on all AirVPN servers. The upgrade requires restarting OpenVPN daemons and some other service. Users connected to servers will be disconnected and servers during upgrade will remain unavailable for two minutes approximately. In order to prevent massive, simultaneous disconnections, we have scheduled a progressive upgrade in 15 days, starting from tomorrow 5 Nov 2020. Please see the exact schedule at the bottom of this post, in the attached PDF file. Servers marked as "OK" have been already upgraded and you can use CHACHA20-POLY1305 with them right now. When should I use CHACHA20-POLY1305 cipher on OpenVPN Data Channel? In general, you should prefer CHACHA20 over AES on those systems which do not support AES-NI (AES New Instructions). CHACHA20 is computationally less onerous, but not less secure, than AES for CPUs that can't rely on AES New Instructions. If you have an AES-NI supporting CPU and system, on the contrary you should prefer AES for higher performance. How can I use CHACHA20-POLY1305 on AirVPN? CHACHA20-POLY1035 on Data Channel is supported by OpenVPN 2.5 or higher versions and OpenVPN3-AirVPN library. In Eddie Android edition, open "Settings" > "AirVPN" > "Encryption algorithm" and select CHACHA20-POLY1305. Eddie Android edition will then filter and connect to VPN servers supporting CHACHA20-POLY1305 and will use the cipher both on Control and Data channels. In our web site Configuration Generator, after you have ticked "Advanced Mode", you can pick OpenVPN version >=2.5, and also select "Prefer CHACHA20-POLY1305 cipher if available". If you're generating a configuration file for Hummingbird, select OpenVPN3-AirVPN: the configuration file needs to be different, because some new directives of OpenVPN 2.5 are not supported in OpenVPN3, and Hummingbird is based on OpenVPN3-AirVPN. In Eddie desktop edition, upgrade to 2.19.6 version first. Then select the above mentioned option. However, most desktop computers support AES-NI, so make sure to check first, because using CHACHA20-POLY1305 on such systems will cause performance harm when you go above 300 Mbit/s (if you stay below that performance, probably you will not notice any difference). Also note that if your system does not have OpenVPN 2.5 or higher version you will not be able to use CHACHA20-POLY1305. If you wish to manually edit your OpenVPN 2.5 profile to prefer CHACHA20 on Data Channel when available: delete directive cipher add the following directive: data-ciphers CHACHA20-POLY1305:AES-256-GCM Pending Upgrade Server Schedule Kind regards and datalove AirVPN Staff

Oh wow... . 2020.11.04 21:00:21 - OpenVPN > open_tun . 2020.11.04 21:00:21 - OpenVPN > wintun device [Local Area Connection] opened It worked ! First time ever on my computer. --- Edit: Wrong thread, now I see the other ones about Eddie 2.19.5, but... well, here it is, it works ! Microsoft Windows [Version 10.0.19042.572] ( aka 20H2 ), WinTUN driver installed and connection to AirVPN was blazing fast ! Typing this message through the VPN 😉

Version 2.19.5 (Wed, 04 Nov 2020 11:22:24 +0000) [bugfix] Minor bugfixes [bugfix] Occasionally wrong order in DNS restoring [change] OpenVPN 2.5.0 - Hummingbird 1.1.0 [change] Minor changes The primary objective of this version is OpenVPN 2.5.0. Other issues are still under investigation, thx. AUR (Arch repository) will be updated ASAP.

Almost post 1 year since this post so here is an update which may help VM customers or others with issues but this was in relation to my own speed issues. The issue is not Airvpn, so stick with Airvpn since they are the best. I still believe Virgin Media's hub3 is the fault (some disagree and I could still be wrong), the issue stems from high packet transfers (usually UDP) so anyone running applications like skype, zoom, webcam, online gaming, torrenting or similar their hub3 will just collapse randomly sometimes down to the slowest speeds possible and after a minute or few will normalize and speeds go back up. Several threads around the net confirm this or similar as shown here: https://community.virginmedia.com/t5/Speed/UDP-issues-on-SuperHub3-collective-thread/td-p/4382720 https://www.ispreview.co.uk/index.php/2020/09/quick-update-for-virgin-media-speed-issues-on-ipv6-tunnels.html The last link from ispreview is a different subject issue but similar in packets and mentions a comment from bmhughes saying anything else other than TCP will cause latency spikes due to the puma chipset fault on the hub3. There are many threads all over vm forums, ispreview articles also with many saying a firmware fix won't fix it since it's been 3 years +, the hub3 router is just faulty But Virgin Media won't admit it or do anything about it. A small glimmer of hope some did say the hub4 may help or process the udp packets a bit better and VM said they will give it free to customers in the right areas so it's a long shot but let's wait and see. Yes there are workarounds (other VPN providers and trying to use unsafe Wireguard etc) but for myself I just ditched the problematic programs (torrents in my case) and moved to newsgroups, hit 16-20Mbs no sweat, so I am maxing out my broadband speeds and this is with AirVPN UK servers with Asus AC86U router. As blues pointed out above you won't magically hit full speeds while under Airvpn and you will have bad or good days from both virgin and your airvpn uk server you just have to try other uk servers or try your bulk downloads after 12 pm midnight when everyone's in bed and not online. Good luck and dont give up !

Which OS are you using?. I am using Windows 10 v2004 + October update and AirVPN v2.19.4 and the Wintun driver is working just fine for me. Problem is it doesn't work with newer versions of the 2.5.0 openvpn ; has been clarified by the dev it is only working with some betas

After installing the Wintun adapters on my Win10 desktop PC a while back my dl speed rose from around 30-45Mbps to around 110-120Mbps on my then 200Mbps Virgin Media broadband. A month ago I upgraded to the VM 500Mbps package and at first I could only get 180-200Mbps D/L speed. I immediately blamed Virgin but when I solved it it was nothing to do with Virgin but my Linksys router. I run the VM SH3.0 in modem mode into my Linksys EA7500 router. I have one cat7 ethernet cable running from the router to my PC and another running to the Samsung tv in my living room. Other than that I have my wifes laptop, mobile and the Virgin Tivo box running on the Linksys Wi-Fi. In the Linksys settings there is a box in the prioritization options which you need to set with your broadband subscription speed x 1024. In my case when I had the VM 200Mbps package it was set at 204,800. When I remembered this I went into the Linksys settings and changed to 512,000 and hey presto I was getting 380 - 400Mbps straight away. I have also found that the server you choose to connect to at AirVPN and the time of day also has a bearing on your connection speed, which is why I have a preferred list of Air servers which have given me excellent d/l speeds in the past and do an online speedtest each time I connect to ensure I get a good connection. Something else is that I only use AirVPN a couple of hours in the early mornings and an occasional Sat/Sun afternoon, perhaps if you are using AirVPN 24/7 these results will not match I don't know but I am quite happy getting 50-75% of my broadband connection via AirVPN and 100% the rest of the time all things considered.

Oh wow, this was a long time ago. Virgin Media claim they're not blocking or traffic shaping OpenVPN traffic but it's clear we don't get the throughput we expect. I'm still unclear on what's causing that. To get around it I had to stunnel to airvpn and then run openvpn over that stunnel. Which sounds like a faff, and to some extent it is, but it works just fine. You might suffere a bit with the CPU overhead of running 2 connections on a Raspberry PI but give it a go and see what happens.

AND, after a quick test, it works fine. I went for the IPv6 Passthrough option. No idea if that's right or wrong, but it works.