Staff

Hello, in all honesty it seems misleading, you might like to ask them, how are we supposed to clarify that...? Kind regards

Yes, we're sorry about that, it's taking longer than expected. Kind regards

Hello! Your analysis is probably correct, however watch out, OpenVPN over SSL will make things worse: the CPU will have to encrypt/decrypt on the fly even more (one additional "encryption layer")you will lose OpenVPN efficiencyyou will have all the problems related to UDP over TCP over TCP All in all for a Raspberry PI, 0.8 MB/s (6.4 Mbit/s) appears as a good performance for an AES-256-CBC throughput, some DD-WRT compatible routers do not even go near to that in real-life testings. Kind regards

Absolutely. Our mission is "defence of net neutrality, privacy and against censorship". The core part of the service covers this mission, but we are thinking also about spin-off projects (under the same mission), that can be: - developed and financed by us, or - developed/managed by members of this community and financed by us, or - simply financed or supported with donations by us. For ideas, we opened this topic. It is possible only with injection of Google Translate javascript in our website pages. We don't allow this kind of trust. In fact, we have removed the "Google Plus" and "Facebook like" in pages of this website, for the same reason. We can add an opt-in option that shows this automatic translations feature. But those who need it can simply install a toolbar, right? If you add these routes with OpenVPN directives, look at the OpenVPN docs about the "route" directive: you can use "vpn_gateway" as alias of the assigned VPN IP, so it doesn't matter if they are dynamic. Note that we implemented recently custom directives in our configuration generator. Feel free to open a separate topic for this if you need more help. Anyway, a new client 2.0 is under development. It provides the user the option to choose a range of IP (route) and choose if it must be it tunneled or not. So, detection of the VPN IP interface is done automatically. Note: the new client will be released for Windows, Linux and OSX, under GPL. Done, feel free to open a separate topic to expand these requests. There are already these kinds of domains with all servers. The idea to maintain other domains with only one server, updated according to lowest usage, is nice. But probably not really usable because of high DNS TTL. We are still thinking about it. The best, right, and correct implementation is planned in our next client: servers have a "score" computed on each server, based on availability, latency time (test performed in background), usage level and other parameters. It will have a auto-connection based on server score, and level/triggers about reconnection to other servers with better scores. Please only be patient, we'll explain in details how it works when we release the first beta. We are working on that: more detailed servers informations (for example bandwidth charts) and improved notification of issues. We are thinking about user-notifications. This feature is under development into the new client. This is very interesting, great hit of our mission. Glastnost/MLab tests must be done by experienced members, we can collect results here and provide how-to support. Subject deserves to be explored. Almost everything of the above is planned in the new client. When we proceed further with the beta stage, test it, and please remind us the missing suggestion. Yes, but probably notifications are not a solution, they are a workaround. We are working on a solution of leaks in our new client. This kind of notification will also available for people that don't want or can't use our client. Anyone here can open a poll, help us probe the community. When we have many topics about the same subject, we can open a section in the forum dedicated to the subject. Absolutely. We will add a payment option soon. We are also investigating other payment gateways, with a special focus to systems than can allow people to buy with cash a prepaid card and use it for our service. Bitcoin: we are currently undecided about advantages/disadvantages of accepting payments directly or use a third-party (like we do now with bitcoincodes). Mail server or seedboxes are under evaluation. Thanks, thanks, thanks to all.

Hello! No, not at all... please consult our guides to prevent any leak in case of unexpected VPN disconnection: https://airvpn.org/forum/15-how-to Kind regards

@Baraka There are no problems with 85.17.207.151. From which VPN server you're unable to access it? Kind regards

Hello! Thank you, we're working on it, one of the frontend servers is under attack. Just browse to an alternate frontend for better web site performance (please contact us in private if you need support to do it). Kind regards

Hello! That's true. You might like to check the fingerprint of our certificate as a more reliable solution. Kind regards

Hello! At the moment we agree with several security researchers according to whom an EV certification is not useful in any way, as also hinted by a Stanford University research in 2006. Since then there also have been interesting discussions according to which EV is just a way to earn more money, something like a marketing solution for gullible ones, not an effective security enhancement. Kind regards

Hello! Yes, it is very probable that it's due to WiFi connection. Kind regards

Hello! You already connecting over UDP. Note that with TCP a replay attack can't be successful in any case, as far as we know (please read the excerpt from the OpenVPN manual, quoted in our post, to understand the reasons). In order to change destination port and protocol with the Air client: after you have picked a server select "Modes". Pick the port/protocol you wish and click "Enter". Incidentally, in addition to TCP ports, try port 80 UDP and 53 UDP, just in case your ISP is performing some shaping or trick toward outbound 443 UDP. Kind regards

Hello! We have no plans to accept Paysafecard at the moment, sorry. Kind regards

Hello! Please see here: https://airvpn.org/topic/4821-losing-contact-with-airvpn/?do=findComment&comment=4828 Kind regards

Hello! Yes, please first enable Chromium logging: http://www.chromium.org/for-testers/enable-logging then send us the logs (only those generated when the tab crashes). Also, when you select "About Chromium", what is the displayed version? Kind regards

Hello! Please right-click on the Air dock icon, select "Logs", click "Copy to clipboard" and paste in your message. Kind regards

Hello! OpenVPN has the ability to connect over a socks 4/5 or http proxy. Connections may or may not require authentication, according to how the proxy is configured. You need to connect over a proxy if you're behind a proxy (according to your questions, very probably you are not). You might like to connect over a proxy, even if you're not behind a proxy, in special cases (a didactic example is here https://airvpn.org/tor). Please spend 2 minutes to read the instructions in the configuration generator page. If you click on "More help" on the configuration generator page, you will see the answers to your questions. FAQ are also an important resource for more details. FAQ are available here: https://airvpn.org/forum/24-frequently-asked-questions Kind regards

This guide shows how to set rules to prevent leaks in case of unexpected VPN disconnection and provides you with clear scripts ready to be used with basic modifications on Red Hat Enterprise Linux and RHEL rebuilds such as Oracle Linux, Scientific Linux, X/OS, CentOS etc. THANKS TO JESSEZ - ORIGINAL POST BY JESSEZ (minor editing & clean-up by Air staff) This method requires the ipset package: sudo yum install ipsetRHEL 6 and rebuilds (Oracle Linux, Scientific Linux and CentOS) do not have a kmod-ipset that I could find. The ip_set module has to be loaded manually as neither netfilter, iptables nor conntrack call the module themselves. As far as I know some Linux distros do have a kmod for ip_set so that would make usage of sysconfig/ipset.conf not necessary and also could cause a boot-time error (fatal nor not). The ip_set module has to be loaded and a script run to load the ip_set script (creates and contains the AirVPN server IP addresses) so that there is a table to be read by the time iptables_restore runs (otherwise iptables_restore throws the error that no ipset "airvpn" exists). So there are 3 files. The first and the second file can be found attached to this message. The last one is a system file that needs a modification. 1 /etc/sysconfig/ipset.conf This script tests whether the ip_set module is already loaded. If not it loads it into the kernel (modprobe). ipset.conf.txt 2 /etc/sysconfig/ipset-airvpn.sh This file creates and fills the ip_set table of AirVPN server addresses. I haven't listed the servers, so that no-one can just open the file and get the server IPs. Add the ones you want where the a.b.c.d 's are. Add or subtract lines as necessary. I think I added enough buffers so that all the servers should be able to go into the table (which lives in RAM while the system is up and is lost at shutdown/re-start). After running the script use: sudo ipset -L airvpn -to make sure all the servers you added to the script are there (It's easiest just to count the lines if you know how many servers you added in the first place), if not, change the part: hashsize 65536 to the next larger: hashsize 131072 (doing this obviously eats up RAM, so don't change it unless you need to) and note that the hashsize can start at 1024 and can only be a power of 2 (1024, 2048, 4096, ..., 131072...) If you're only using one or two servers and you need to save RAM, just change it down, re-run the script and issue the command sudo ipset -L airvpn again to check that all the desired servers are listed. Keep doubling the hashsize until they are. If anyone is wondering about the -exist option, it's there so that in case of accidental duplication of an IP address the script won't fail. iptables-airvpn_2013-01-19.txt 3 /etc/init.d/iptables This is the system file, so be careful; add 2 new lines that become line 55 and line 56: # Load /etc/sysconfig/ipset-airvpn.sh to make the airvpn table sh /etc/sysconfig/ipset-airvpn.sh Ok, that should be it, iptables and the "airvpn" ipset table should now survive a reboot with no errors. Test by rebooting, and trying Internet access of any and /or several kind(s) before starting a VPN connection when the desktop is up. If it's working you will have no Internet before starting a VPN connection, and you will be able to connect to any of the servers you added to ipset-airvpn.sh without OpenVPN throwing an error (probably: write UDPv4 []: Operation not permitted (code=1)). Note: rename the attached files according to the names given above. Put the files in the appropriate folders as listed above. Regards, jz

Hello! We don't detect any problem with Chromium: Version 26.0.1410.43 Debian 7.0 (189671) Which Chromium version crashes in your system when you click the "Forums" tab? The differences you detect with YouTube videos are also quite puzzling (we do not detect any difference between Iceweasel (Debian), Firefox (Debian), Chrome (Windows) and Chromium (Debian)), just for information do you play them "in Flash" or "in HTML5"? Kind regards

Hello! Normally the opposite is true (UDP over UDP is much better for streaming). Have you checked in the logs if your system experiences packet loss or packet fragmentation? If in doubt do not hesitate to send us your client logs (taken after some minutes your system is connected) for a check. Kind regards

Hello! The icon should be blue. Can you please send us the client logs? NOTE: our VPN servers are not virtual, they are all real, dedicated servers, with dedicated bandwidth. EDIT: please test with Windows firewall disabled. It's important to know that an application "authorized" by the Windows firewall on some network, will not be automatically authorized on any other network. Probably your Windows firewall is just dropping incoming packets for uTorrent. Kind regards

Hello! Sorry, they should not show up, you apparently have a DNS leak. Please fix it following our guides. For the records, we are building a knowledge base to understand why our customers are willing to use OpenVPN over SSL, which should be avoided if not strictly necessary (like it is in China and Iran, where anyway OpenVPN over SSH may be better), if it's all right with you, would you please tell us why you need to connect over OpenVPN over SSL? Feel free not to answer or to answer only in private. Kind regards

Hello! When you connect to an Air VPN server, routes are pushed so that all the client traffic is tunneled. If you wish some application NOT to be tunneled, you can bind it to your physical network card (in your case, the WiFi card). If an application lacks the bind ability, you could bind it with ForceBindIP in Windows. Kind regards

Hello! Actually there's a problem with IDENT, the IRC server will try to contact your daemon on port 113 (the IRC server can't know the remotely forwarded port on our system) and we don't allow remote forwarding of low ports. There are some security issues with the ident protocol and no ident daemon runs on any VPN server, we need to think about it. Is this a serious issue, for example your favorite IRC server(s) will not let your client in when it does not receive a reply from an ident daemon? Kind regards

Hello! You're right, something happened on the image hosting service (we see that the images were not uploaded on our servers, but they were just fine some time ago... something went wrong when we migrated to the new system). As a temporary, quick work-around, refer to the pictures here: http://www.pixhost.org/show/3984/15431130_1-tomato_config_basic.png http://www.pixhost.org/show/3984/15431131_2-tomato_config_adv.png or to the guide in the "Enter" menu https://airvpn.org/tomato to get the parameters you miss for the configuration. Feel free to contact us for any doubt in any field. EDIT: the pics in the original post have been fixed. Kind regards

Hello! We inform you that a planned maintenance on server CASTOR (NL) will begin on 21-May-2013 at 11.00 AM CET+1. The server needs some tests and software maintenance and upgrades. The expected maintenance time is a few hours. Please take note that during the maintenance we will need to shut down OpenVPN, therefore all clients will be disconnected. We strongly recommend that clients connected to Castor switch to any other AirVPN server before the maintenance starts. List of available servers: https://airvpn.org/status Kind regards