Staff

Hello! There are no problems on the USA servers. You can check anytime the servers status on our real time servers monitor (click "Status" on the upper menu). https://airvpn.org/status Can you please send us your client connection logs? Kind regards

Hello, maybe you're running Tunnelblick 3.2.8 or 3.2.9 which are not compatible with OS X 10.8.x. Feel free to send us Tunnelblick logs. Kind regards

Hello, please search the forum with keywords: split traffic Kind regards

Hello, the server rack has a 50 minutes power outage. Problem promptly fixed by the datacenter. Kind regards

Hello! Connections to our OpenVPN servers can be either over UDP or over TCP. Any protocol from/to your system is encapsulated within UDP or TCP, according to the protocol you pick for the connection to an OpenVPN server. Please see here: https://airvpn.org/faq/udp_vs_tcp Kind regards

Hello! DNS traffic is encrypted & tunneled as well. Set 10.4.0.1 as primary DNS IP address to use our VPN DNS. Check here: http://ipleak.net Kind regards

Hello, it's not an artifact, and all the services you're using return the correct data. Everything is fine, this is our anti-blocking system working. Please do not publish IP addresses. Kind regards

Hello! Adding a VPN server in South Korea is very problematic, however you just probably need routing to bypass geo-IP-location based blocking, can you confirm this? From https://airvpn.org/faq/locations Please note that, even if we decide to setup a routing servers in South Korea, we will need the full range of the game service domain names and/or servers IP addresses, otherwise we can't implement the bypass system. Kind regards

Hello, ok. Unless you have some packet filtering tool that slows down the flow (if it's the case, just disable it), your ISP is shaping UDP traffic, and with TCP probably you're already getting the best possible performance. Kind regards

@mordants Hello, about trackers, it's normal, probably you have missed this: https://airvpn.org/topic/9499-connecting-to-trackers-fails-from-different-servers/?do=findComment&comment=10370 About DNS, check for DNS leaks (if you run Windows). Kind regards

Hello, getting higher performance with TCP instead of UDP strongly suggests that your ISP is performing port shaping. However your tests are not reliable, so maybe there's a bias from them. Kind regards

Hello, have you tested different servers (only 1 Gbit/s servers: 100 Mbit/s servers will probably never give you higher performance than the one you report)? How do you perform the speed test? With such a bandwidth, a short-in-time speed test is not reliable. Prefer UDP, if your ISP does not cap UDP traffic. Kind regards

Hi, yes, you can! All you need is the hash. If you have destroyed the magnet link as well, just re-create it with the hash. Kind regards By re-create it do you mean be sure that I have exactly all of the same files in place and use the same piece size so that the torrent I create from scratch has the same hash? I believe I read somewhere that the hash will come out the same under these circumsutances. But I have never tried it myself. Hello! Correct. If you have modified the files you can't get the same hash (hash collisions are very unlikely - otherwise the p2p infrastructure might be easily poisoned to the point to collapse), and the files can't be seeded again as before, trackers or not (trackers are irrelevant even in this case). They will be seeded according to the new hash, therefore with a new magnet link (which can specify or not trackers) or a new torrent file. Kind regards

Hello, block circumvention should now work on all US servers and all NL servers. We have scheduled to check Herculis. Kind regards

Hello, please continue to report, if you wish, blocked trackers (exact url) on specific servers. Kind regards

Hi, yes, you can! All you need is the hash. If you have destroyed the magnet link as well, just re-create it with the hash. Kind regards

Hello! It's worth that you try OpenVPN over SSH, and OpenVPN over SSL. https://airvpn.org/ssh https://airvpn.org/ssl Kind regards

@flexon11 Is there any correlation with bigfish9 report? Kind regards

Hello, thank you very much for the report. Have you also tried port 53 UDP? Kind regards

Hello, sure, you have already the solution under your eyes. Up & down directives in .ovpn files can be used to execute a script. Write your own script for "up" which adds nameserver 10.4.0.1 in head, and a "down" script which removes (comment) it. Or modify properly the update-resolv-conf. Or... well, there are probably so many ways to do it. Kind regards

Hello! Currently the choice is random. We are working to implement a system which will select dynamically the best available server for regions according to the result of a formula based on definite parameters. You will have more details in the future. Kind regards

Hello! The blue bars show the total portion of currently exploited bandwidth of each server (updated every 60 seconds). The numbers you refer to are exploited bandwidth/total available bandwidth Kind regards

Hello, put in /etc/resolvconf/resolv.conf.d/head 10.4.0.1 as first nameserver, and your internal nameserver after it, for example nameserver 10.4.0.1 nameserver Kind regards

Hello! 1) No. 2) It's impossible to answer definitely: there are just too many unknown factors. Feel free to ask for a trial and test. 3) Very very consistent. The general availability of the service was 99.8% in 2012. On top of that most of the 0.2% downtime (a total of ~16 hours out of ~8760) was related to the web site accessibility, not to the VPN servers. 2013 is currently going slightly worse (99.6%) but that's due to some massive system changes we performed and some initial problems related to the new clustered database, so it can be reasonably expected that the uptime in the second semester will be as high as in 2012. Kind regards

Hello, "ping google.com" output is missing, can you please post it as well? Anyway, we see that you have resolvconf installed. Assuming that it's a DNS issue, add to your OpenVPN configuration file(s) the following directives: script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf An alternative way is adding those directives in the "Custom directives" field of our configuration generator. This field becomes available when you tick "Advanced Mode". "up & down" and the .../openvpn/update-resolv-conf script are the very same lines and the same script that you have commented out in the resolv.conf file. At a first glance it's unclear whether the rest of your resolv.conf can set DNS according to the DNS-push of our servers (probably not). Setting those proper OpenVPN directives should solve the issue at its roots. The VPN DNS server IP address that is accessible from any VPN subnet is 10.4.0.1, anyway setting up & down in the OpenVPN configuration file is probably the most elegant solution when one has resolvconf installed. Kind regards