Staff

@rained23 Hello! We do not cap the bandwidth. Trial accounts are premium accounts, they are absolutely identical, there is no difference in the system. You might like to watch the FAQs to see the reasons for which you may experiment different bandwidth at different times. Please try to switch servers in order to determine which server can give you the best performance. Please do not hesitate to contact us for any further information. Kind regards

This is an important update about connecting AirVPN over TOR. When performing critical data transmission, please always evaluate whether it's the case to harden security with this kind of connection. The reported example is a working and tested configuration with Tor Browser Bundle, that is highly recommended by the TOR Project. https://airvpn.org/index.php?option=com_content&view=article&id=64&Itemid=122 Kind regards

Hello! We're sorry, we are not able to reproduce that behaviour. KTorrent in its default configuration, and without remote port forwarding, appears to work just fine. Please note: without remote port forwarding, initial seeding is not possible. This is normal, not a fault of KTorrent. However, there can be a case for which KTorrent can NOT work. In its default configuration, UDP port for UDP trackers is 4444 and DHT is off. Now, if you share a torrent with UDP tracker(s), if the tracker(s) can't contact your client and/or is/are down, there's no way for KTorrent to know which peers share the file pointed by the torrent. Solution: log in our website, select menu "Member"->"Forwarded ports". Forward two ports and remember the port numbers. Then, configure KTorrent ports so that they match the two ports you have just remotely forwarded. To do so, select menu "Settings"->"Configure KTorrent". Click on tab "Network". Type in the fields "UDP tracker port" and "Port" the two ports you have previously forwarded. In this way you'll be able to do initial seeding and to receive incoming connections. Finally, enable DHT. Click on tab "BitTorrent" and tick the box near "Use DHT to get additional peers". DHT will enable the client to find peers even when trackers are down. Furthermore, it will enable your client to share trackerless torrents and trackerless magnet links. Please note that when you forward ports, your computer will be reachable from the Internet on those ports. Let us know if the above configuration solves your problem. Kind regards

Hello! AirVPN client v.1.6 for Windows is now available. Changelogs: - Added support for OpenVPN connections over a SOCKS proxy - Fixed a problem with HTTP proxy AirVPN 1.6 comes pre-packaged with OpenVPN 2.2.1. When you run the client, it will detect if you need an update of your OpenVPN package, and you can decide to authorize it to make the upgrade (or a first installation) automatically or not. Kind regards AirVPN admins

Hello! Of course, your position is calculated as described in the article, it's not based only on your IP address. You have to disable ALL the geolocation features (not only GPS tracking), as described in the article. Kind regards

Hello! Free access is reserved ONLY to activists who work in freedom of expression hostile countries and can't afford to pay a premium subscription. It is a full, premium access. Fur such purposes, the Telecomix cluster can provide support. Please do not hesitate to contact us for any further information. Kind regards

Hello! Usually geolocation software use a combination of GPS, cell site triangulation and local WiFi networks scanning to disclose your position with accuracy (A-GPS, that is Assisted GPS). If Location Services are on, connection to a VPN server may be necessary but not sufficient in order to hide your real position. You might like to read the following article: http://socialtimes.com/turn-off-location-services-on-android-phones_b59219 Kind regards

Hello! Thank you. It is related to the DDoS attack suffered today. When the Air client tried to contact the db server, this was frequently unable to respond within the time limit, triggering an unexpected behaviour. Kind regards

Hello! Most customers can reach much higher speeds, other unfortunately just can't. The reasons are clearly explained in the FAQ. Please do not hesitate to contact us for any further information. Kind regards

Hello! From the FAQ: Which speed can I expect when I am connected to the VPN? Speed may vary according to several conditions which are intrinsic to how the Internet works. We guarantee on our servers, switches and lines an allocated minimum bandwidth of 4 Mbit/s per account (worst case scenario), while the upper limit is 50 Mbit/s. Please note that this is the bandwidth which is "allocated" for each account: the bandwidth you can obtain depends also on your provider conditions, peering and several further conditions. Please contact us to test speed from your ISP connection. That said, you can have a look at our real time monitor to determine whether there's a server near or on capacity, and pick a server with more free bandwidth: https://airvpn.org/index.php?option=com_air&view=servers&Itemid=107 Please do not hesitate to contact us for any further information. Kind regards

wingzeroxdelta5 wrote: Hello! There was an error in the FAQ, now it has been fixed. Also, port 4444 has now been forwarded for your account. We were using that port for test purposes. Please do not hesitate to contact us for any further information. Kind regards

Hello! We're very glad to inform you that a new 100 Mbit/s server located in the Netherlands is available: Leonis. The AirVPN client will show automatically this new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificate/key generator (menu "Member"->"Access without our client"). The server accepts connections on port 53, 80 and 443 UDP and TCP. As usual, no traffic limits, no logs and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN admins

99zeros wrote: Hello! The port was already reserved to another account. There can't be two or more accounts forwarding the same port. Unfortunately, we are aware that BitWise does not allow to change the port. Anyway, that account was a trial one, so we are going now to free the port and forward it to your account. On a side note, if you use BitWise for private IM, please be aware that in its free version it does not provide effective protection. It's not open source, it has a low level encryption (Blowfish 128 bit, RSA 512 bit), there's no proper method to validate your contacts and the key is not generated and owned by you. If this is your case, you should consider to upgrade to BitWise Plus/Professional. A much better solution for secure IM (but not for voice calls), which is also free and open source and widely interoperable with so many IM services, is Pidgin+OTR. http://www.cypherpunks.ca/otr/ Please do not hesitate to contact us for any further information. Kind regards

perhentian wrote: Thank you very much! Kind regards

thigger wrote: Yeah - we agreed it's an excellent idea to have separate entry and exit IPs; we were just confused by the SNAT/ip rewriting. However with your clue I think I've found a better reason as to why the rewriting is a good idea. Without it, if an attacker was monitoring an AirVPN user's connection they could match the connection to a forwarded port by sending a packet to the VPN exit with the source ip spoofed to be the VPN's entry ip. The user's machine would send a reply outside the VPN tunnel, which would be seen by the attacker and confirm the user was using that port. Rewriting/SNATing means that the reply packet goes down the tunnel, preventing the attack. Is that the main reason? Thanks for the fascinating insight into how AirVPN works. Hello! Yes, exactly. It is a dangerous attack. One of us has also verified in the last days that this attack is possible with some VPN services. We have seen that it was also discussed in the Wilders Security Forums a couple of years ago (unfortunately no real solution was suggested at the time, except the unsatisfactory solution to prevent users to forward ports) so hopefully VPN providers are getting aware of that. It appears to be completely prevented by our current setup. The thread is becoming more and more interesting; if you (or anybody reading) have any idea on further attacks that you think might be successful with our current setup, please do not hesitate to share. We always do our best to harden security and we keep ourselves constantly updated from security forums and bulletins, but independent peer reviews and suggestions are anyway vital. Let's take it as a challenge where nobody can lose. Kind regards

Hello and thank you! We're glad to hear that the problems is fixed. Please do not hesitate to contact us for any further information. Kind regards

thigger wrote: Again, correct! Just in case, any second guess? Congratulations! We couldn't think of an obvious second attack - the rewritten header is encrypted until it reaches the AirVPN user so shouldn't be vulnerable en-route; the only places to see the header rewritten but unencrypted are at AirVPN (but you guys have access to the un-rewritten header too) and on the AirVPN user's machine - so we figured the only person losing information by the rewriting is the AirVPN user. I think that's why we found it confusing - we'd assumed any changes were to protect the anonymity of AirVPN users rather than the anonymity of TOR or other users connecting to a service run by an AirVPN user! Hello! That's also important, since "other users connecting to a service run by an AirVPN user" might be AirVPN users too. Furthermore, some Air users might be malicious users. Anyway, there are further considerations. The packets with final destination the entry-IP server address a client is connected to are sent outside the encrypted tunnel. This is a correct behaviour; however, when the entry and the exit-IP are the same, in the event in which two or more users are connected to the same VPN server and try to exchange data between their services (maybe even unaware of that), one of them or both would send out unencrypted packets. A not uncommon situation is a p2p environment, in which the VPN server IP address and the port forwarded by the client are inserted in the DHT table and/or in a tracker peerlist. The torrent client of some (other or the same) VPN user sharing the file identified by the same torrent or magnet link would see that IP address:port as a good IP address:port to try a connection to, and would perform at least one connection attempt which would be routed outside the tunnel (if the user's firewall is not properly configured to prevent that). Our servers (and hopefully any server of any VPN service which offers remote port forwarding) always dropped those packets for security, otherwise a copyright troll could just subscribe to the service and start seeding something apparently tasty to disclose the real IP address of the VPN users who did not set properly their firewall. However, this is not a completely satisfactory solution, because a malicious entity which wiretaps locally the connections of a user could realize that he/she is using a certain protocol. Not a relevant information, but you never know when you deal with repressive regimes. Furthermore, some rotten ISPs perform bandwidth caps against p2p: in this case a single packet outside the tunnel might trigger the cap for seconds or even minutes. With separate entry and exit-IP addresses, we solve simultaneously both this issue and the issue you noticed, without requiring our users any additional firewall rule and with no need to renounce to remote port forwarding. Thank you from the techies! Kind regards

CatsAreGods wrote: Hello! We have checked that your account is authorized to access all the servers. In the moment of this writing, your account is connected properly to one of the VPN servers: is the problem solved? About the helpdesk, we don't detect any problem with Chrome. Your ticket on the Helpdesk has been submitted and received properly. We're looking forward to hearing from you. Kind regards

thigger wrote: Hello! Don't worry, security through obscurity is a very dangerous path, so we try to avoid it. A little bit unclear... if you refer to a packet coming "from the Internet" with destination the exit-IP of a VPN server, it is not (necessarily) encrypted, it depends on how and by whom that packet was sent. If a client of ours sends a packet to the exit-IP of a VPN server (for example a client with a service which listens and replies), it is encrypted on the client side together with the payload before it gets out of the client machine. The unencrypted new header will have, as destination, the entry-IP of that VPN server. Yes, that's right. Again, correct! Just in case, any second guess? Congratulations! Kind regards

blknit wrote: Hello! Excellent! It was our problem on SNAT. While Windows and Max OSX appear to accept to send replies inside the tunnel to incoming connections (TCP) from the entry-IP address of VPN servers (further investigations on this are in progress, since this does not appear a "good" behaviour, because it seems to override on the client side the push route commands sent by our server), Linux does not. Therefore listening services (behind our servers) based on Win and Mac worked. These facts put us on the wrong track, pointing us to a client side problem, while it was not, and causing the huge delay in solving the problem. Now incoming connections packets arrive from the exit-IP of the servers, solving the root of the problem. Linux behaviour is the "correct" behaviour, in the sense that it fully complies to OpenVPN directives and commands sent from our servers. Please do not hesitate to contact us for any further information. Kind regards

epoair wrote: Hello! Contrarily to most VPN providers, we guarantee a minimum allocated bandwidth for each customer and we provide a real time monitor of the servers to check the available bandwidth on each of them. The speed you reach with BitTorrent is ok (12.5 Mbit/s you reported on the previous message), while speed with other protocols seems too low. Anyway the speedtest you reported on your first message with speedtest looks fine. First of all, to wipe out any doubt about torrent client leaks, please perform the test available at http://checkmytorrentip.com/ while you are connected to one of our servers. You can see the IP you are visible on the Internet looking at the central bottom box of our webpages. Check carefully that there's no IP leak: during the test, the site and the tracker must never see your real IP address, instead they must report the exit-IP address of the VPN server you're connected to (the IP address you see in our webpages after the connection is established). The test will take you just a couple of minutes. We're looking forward to hearing from you. Kind regards

thigger wrote: Hello! Yes, you're 100% right: forget the previous incorrect statement. And yes, a nice side effect of the setup is to make correlation attacks much more difficult. We'll also add in the FAQ your suggestion for uTorrent which can improve performance. Technically, we don't do masquerading (in the meaning of MASQUERADE in iptables), but DNAT and SNAT (which is a form of masquerading according to some older definitions; in some literature, dynamic NAT is also called masquerading). Thank you for your cooperation! Kind regards

triad575 wrote: Hello! We detected and fixed an issue with UDP packets. Now KAD works properly (just please be aware that, randomly, eMule says "Firewalled" even though it's not true). The problem lied in the source of the UDP packets when we added the exit-IP and entry-IP rules. They came from the entry-IP instead of the exit-IP, causing the answer packets by eMule to be routed outside the tunnel and be dropped. For all the details, see this tasty thread: https://airvpn.org/index.php?option=com_kunena&Itemid=55&func=view&catid=3&id=1276 Kind regards

thigger wrote: Hello! Problem detected and fixed on all servers. Now you'll see incoming packets from the exit-IP, not the entry-IP. In this way the UDP reply will be routed inside the tunnel (if the reply was routed to the entry-IP, it would go unencrypted outside the tunnel to the entry-IP, and then dropped by the VPN servers - this was the cause of the problem). We apologize for the inconvenience. Of course, you will still be able to see real IP sources and destinations by capturing packets on the tun interface. Thank you for your cooperation and let us know if everything's fine now! Kind regards

thigger wrote: That's the case with all VPN connections - but what I was wondering about is the specific feature of AirVPN where incoming packets on the tun0 interface (not the underlying eth0 interface) are masqueraded to appear to be coming from the vpn entry ip as mentioned above: I've had a look into it, and it appeared my torrent client was rejecting incoming tcp connections because they had the same ip address as previous ones (and not getting any udp ones, but that's in my previous post). The solution for uTorrent was to enable 'bt.allow_same_ip' in the advanced preferences; then you can see multiple incoming connections - all appearing to have the ip of the vpn server's entry point. Hello again! That does not appear normal at all. uTorrent should be working swiftly with bt.allow_same_ip set to "false". On the other hand, a web server could not work if the encrypted packets header were overwritten with the VPN server address, because the webserver would not know to which IP address to answer (while your web server behind AirVPN works fine even on Sirius, right?). Is it possible that your uTorrent tries to listen to your ethernet or wireless adapter, trying to bypass the tun interface on the incoming connections? Can you please do packet capture on your TUN/TAP interface to verify whether the packets come from the correct IP address (you should see packets coming from addressess different of the VPN IP addresses). Kind regards