Staff

@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

Hello, at the end of initialization please do not kill OpenVPN and at your convenience send us the output of the commands ping 10.4.0.1 ping google.com ping 8.8.8.8 and (as root) the output of the command "route -n" and the content of your /etc/resolv.conf file. Kind regards

Hello! The crucial rules are: Allow TCP In/Out From In [Home Network] To In [Home Network] Where Source Port Is Any And Destination Port Is Any Allow UDP In/Out From In [Home Network] To In [Home Network] Where Source Port Is Any And Destination Port Is Not 53 Allow ICMP In/Out From In [Home Network] To In [Home Network] Where ICMP Message Is Any They allow communications between everything defined inside [Home Network] Network Zone. So when you are in the described situation, modify the [Home Network] Network Zone. Normally it is defined as a wide IP range, for example 192.168.0.0-->192.168.255.255 Once you are connected to the WiFI hot-spot of the coffee-shop etc., detect the IP address of the router/hot-spot. Open a command prompt and type the command "ipconfig". Read the values of your physical WiFi network card ("LAN Wireless" or something similar): "IPv4 address" and "Default Gateway". Let's say, just for example, that they are respectively 192.168.0.155 and 192.168.0.1. It means that your computer is 192.168.0.155 in the network, and the default gateway (the coffe-shop router or hot-spot for example) is 192.168.0.1. Now you want to allow communications ONLY between your computer and that gateway, so in the [Home Network] Network Zone just put those 2 IP addresses (instead of an IP range). Save the changes and you're ready to connect to an Air server. Kind regards

Hello! After a connection (or an alleged connection) has been performed, can you please open a shell and send us the output of the following commands: ping 10.4.0.1 ping google.com Also, please send us the connection logs (right-click the Air client dock icon, select "Logs", click "Copy to clipboard" and paste in your message). Kind regards

Hello! To begin with, you should check not within those 3 seconds, but in the time between two occurrences of those management "connect/disconnect" brief cycles. Realistically, it's not possible that a VPN connection is dropped, routing table restored, connection re-established with TLS handshake, routes pushed again etc. in 3-4 seconds, so it might just be a management misleading behavior. Kind regards

Hello! The logs show that the initial connection is just fine. The management seems to provide misleading information, though, during those 4-5 seconds at 0:29 and 0:33. Can you please check that during the whole time in between two series of similar entries your connection in reality has not dropped? Kind regards

Hello! There are multiple problems. If you wish to access an Air server, your OpenVPN will have to work in "client mode", not in server mode. In this case, the destination port, the encryption cipher, the hash algorithm, the client certificate, the server certificate, the key, the DH PEM, the configuration file, the VPN server entry-IP address are wrong. Additionally, account "doublex" is not authorized to access any Air VPN server because it lacks a subscription. Never been subscribed before, it also lacks a key (which will be generated with a subscription). Once the account has a subscription, generate certificates, configuration file and key with our Configuration Generator and follow this guide: https://airvpn.org/ddwrt to configure OpenVPN as a client. We do not provide specific support to set up an OpenVPN server, but you can find several good guides on the Internet. Kind regards

Hello! a) It might be a problem in the management, not in the OpenVPN client connection itself. Chances are that your connection is actually always on, but of course further investigation is mandatory. Could you please post the complete logs for an additional check? c) Unfortunately not with the DD-WRT web interface alone. Kind regards

Hello! It's not currently not possible to do that with the Air client 1.8. Use OpenVPN directly. OpenVPNPortable is semi-portable, it will need tun/tap driver installed. Side note: when you launch the Air client, OpenVPN must NOT be running. Kind regards

Hello, the basic concept is that regardless of the key exchange method and cipher used in an end-to-end encrypted connection, both ends are able to see the unencrypted payload (otherwise any gateway of the VPN to the Internet could not work, obviously). That's why you need to add encryption layer(s) in every and each case you can't afford to trust VPN, TOR exit-nodes etc. operators, or the security/safety of their servers. On top of that, not only you can add an encryption layer, but you can also hide your real IP address to the VPN or TOR servers. The additional step is hiding both your traffic AND your IP address, an argument which is treated implicitly in the linked post. One quick method (there are many, this is just a didactic example) is connecting over OpenVPN over TOR a host machine, and connecting over TOR on a guest (virtualized) OS, attached to the host via NAT (setup successfully tested with VirtualBox, but there should be no problems at all with VMWare as well). The resulting setup will therefore have the following features: - on the host machine, traffic is "tunneled over" OpenVPN over TOR ("fixed" circuit) - on the guest machine, traffic (ONLY of the applications configured to connect over TOR proxy) is "tunneled over" TOR (not "fixed" circuit) over OpenVPN over TOR. As a result: AirVPN servers can't see your real IP address, packets payload, origins, destinations, used protocols and applications from/to your VM. Also, the traffic is pushed into two different TOR circuits. While this setup provides very poor performance, it also provides an extraordinarily high anonymity layer (which can be crumbled by human errors of the system operator, social engineering or by a compromised machine with keylogger, spyware etc.) for critical purposes. The above setup should also greatly lower (or maybe even crumble) the efficacy of traffic analysis by an adversary who controls Internet exchanges (see for example http://freehaven.net/anonbib/#murdoch-pet2007 ) but further research on the topic is necessary. Kind regards