Staff

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

Hello! They are some of our OpenVPN servers connection ports, please see here: https://airvpn.org/faq/udp_vs_tcp In case your ISP performs port shaping (i.e. caps bandwidth on some outbound ports) you will see different performances on different ports. Once your system is connected to a VPN server, all its traffic comes and go from/to the same port regardless of protocol, application, source and destination, do not confuse those ports with ports "used" by your applications, which remains specified in the underlying "real" encrypted packets headers. Kind regards

Hello! As a first and strong defense, when you are in a coffee shop modify Comodo global rules to drop packets from any IP address inside the network, except to/from the gateway. Our guide for Windows and Comodo is specifically thought to ALLOW communications within the local network, because it is thought for home and office users. Kind regards

Hello! We'll investigate. At the moment we are unable to detect any problem with the authoritative DNS for airvpn.org, and actually earth.airvpn.org resolves correctly to all IP addresses with every public DNS server we have tested. What happens if you use OpenNIC DNS http://www.opennicproject.org/ ? Does the problem persist? Kind regards

Hello! Yes. Be careful of correlations. Kind regards

Hello! It should not depend on us. Can you please try again now? If the problem persists use a configuration for a single server or a different area. Kind regards

Hello! Can you please perform a test while the firewall is disabled? Kind regards

Hello! Please confirm your torrent client (it can't be Tunnelblick) and enable DHT. Kind regards

Hello! 1. Perfectly consistent. 2. Normally it's not possible. This is one of the most common reasons for which our service is used: it does not matter if an adversary wiretaps any point between your computer and our servers, he/she can't do anything with the captured traffic (no analysis, no decryption, no injection of forged packets are possible). It's very important, however, that your computer is not compromised. Keyloggers, spyware etc. obviously render any encryption layer useless. 3. Normally not, VPNs are used nowadays by any small and big company, it's a perfectly normal usage. Kind regards

Hello! It's possible with policy routing, Tomato supports policy routing. Detect the IP address of the Roku device (i.e. the local IP address whose traffic you do NOT want to be tunneled), all your Tomato interfaces names (for example tun11, br0...) and follow this: http://serverfault.com/questions/382498/howto-only-tunnel-specific-hosts-route-through-openvpn-client-on-tomato In the above thread, jump directly to the last answer by grdnkln, it's probably the most elegant solution (anyway also the solution proposed by Quint works, according to one of our customers report). Security/privacy/anonymity threat with split traffic may become a complex affair, but as long as you keep strictly separated identities on different devices there's no serious risk. Keeping separate identities in this context means that you never mix accounts, traffic, data... between the Roku device and the devices which, on the contrary, are tunneled. Kind regards