Staff

Hello! Yes, we fully support remote port forwarding. You can't forward ports lower than 2048, but you can remap any port to any other local port. Port 88, as well as any other non-forwarded port or any other port lower than 2048, is closed to every client. You can forward a maximum of 20 ports. When you perform the test, please make sure that the service behind the VPN server is running and listening to the correct port. Kind regards

Hello! We're very sorry, it's not possible to have OpenVPN connect over SSL/SSH or over a proxy when Tunnelblick is the wrapper. You should run OpenVPN directly. Anyway, OpenVPN over SSH/SSL should be used only when absolutely unavoidable (for example from China; since your connection works fine with direct OpenVPN, it's probably a waste of time and resources (but also an interesting didactic exercise ) to connect OpenVPN over SSH. Kind regards

@gevero Hello! Various ARM processors are not probably able to decrypt/encrypt more than 10-11 Mbit/s of AES-256-CBC throughput, which is very near to the performance you already experience. Kind regards

Hello, you need to paste from "----- BEGIN CERTIFICATE" up to "END CERTIFICATE -----" Kind regards

Hello! That's correct, an account without a subscription can't access the Configuration Generator. Your account does not appear to have any valid subscription. Please do not hesitate to open a ticket if you think this is a mistake. Please include your payment details. Kind regards

Hello! The error might lie in point 3. You can't remap ports with torrent clients, because the torrent clients will notify the peers and the trackers of the port number which is configured in the client itself. If that port does not match with the port to be reached on the public IP address, your torrent client can't be contacted. A clarification: is OpenVPN running on the router where Rapsberry is connected to? If so, has a DNAT been configured on that router according to our guide, to properly forward packets to the Rapsberry device? Kind regards

Hello! See our previous answer. It's unclear what you mean. You need to paste the whole certificate, from "----- BEGIN CERTIFICATE" up to "END CERTIFICATE -----" You have to paste both the ca.crt and the user.crt certificates, as well as the user.key Kind regards

Hello! You can also resolve .airvpn.org to get all the VPN servers entry-IP addresses of that country. For example: $ dig @10.4.0.1 de.airvpn.org +short 46.165.208.65 46.165.208.69 46.165.208.70 178.162.198.40 178.162.198.102 178.162.198.103 Kind regards

Hello! The problem is here: 18.03.2014 - 14:33 TLS: Initial packet from [AF_INET]94.242.205.234:443, sid=d48662f3 e135f48b 18.03.2014 - 14:34 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) As you can see, an incoming packet from the VPN server arrives to your node. Please check your network connectivity. In particular make sure that no firewall is blocking outgoing OpenVPN packets. Please also try connection in TCP mode, to perform a comparison. Kind regards

This is the text we sent to TorrentFreak a few minutes ago: Hello Ernesto and thank you for your inquiry. 1. No, we don't keep any log that might be exploited to reveal customers' personal data during connections, including real IP address. For example OpenVPN logs are sent to /dev/null (Air is based on OpenVPN). Our privacy policy is available here: https://airvpn.org/privacy On top of that our VPN servers do not maintain any account database. 2. Italy. We do not share any information with any 3rd party. 3. Automatic triggering based on patterns to detect and if possible block as soon as possible various types of attacks (for example UDP floods) against or from our servers. 4. They are ignored. Now and then we reply asking for a more substantiated proof and asking to disclose the technical method according to which a takedown notice has been prepared, but so far none of the entities we queried disclosed such information, in absence of which the notices pertaining to p2p are simply vague and unproven claims from some private entity. 5. No help can be given about past connections because we don't log, monitor or inspect our clients traffic, and we don't and can't require a proof of identity from our customers. However, if the court order pertains to presumed actions which infringe our Terms of Service and in particular that in any way violate, directly or indirectly, or aid the violation of, the ECHR, we can try to help the court in the best way we can with subsequent investigations and if possible with the help of proper and competent authorities. 6. Yes. p2p protocols are perhaps a set of the most exciting protocols invented in the last 12-13 years, so they are actively encouraged on every server. We do not discriminate against any application or protocol, in compliance with our mission and to stay a mere conduit of data. 7. We accept Bitcoin, many credit cards, PayPal. Each payment is linked to an account only in order to provide service delivery and to comply to our refund policy. 8. First of all it is mandatory that the key exchange is not exploitable. Even the strongest encryption is useless if the key exchange is flawed. In light of the most recent releases about how NSA attacks VPNs and VoIP, it is essential that you pick a service which relies on ephemeral key exchange, that correctly implements Perfect Forward Secrecy and that correctly implements a robust key exchange procedure. That's not trivial: for example H.323 VoIP protocol could be "broken" by NSA and other entities because, even though it employs DHE, which is a very wise choice, the implementation is wrong: vendors skip the TLS/etc. encryption of the signaling channel and the Diffie-Helmann keys are unprotected. Finally (and this might be a surprise for some people) we would not recommend ECC (Elliptic Curve Cryptography) at the moment. We momentarily avoid ECC (Elliptic Curve Cryptography) in Control Channel, Data Channel and in key exchange, according to Bruce Schneier's suggestions and keeping into account reasonable suspects of deliberate poisoning and weakening of ECC (with possible backdoors) by NSA in cooperation with industry. We put into practice the recommendations of security expert and best practices on our setup, based exclusively on OpenVPN with the following features: Data Channel: AES-256-CBC Control Channel: HMAC SHA1 RSA keys size: 2048 bit PFS (Perfect Forward Secrecy): yes. TLS re-keying is performed by default every 60 minutes through DHE as well as at each new connection. As an additional option the re-keying time interval can be lowered by the client unilaterally. The client key is used to authorize the access to the system, not to encrypt the data channel, so that even if an adversary catches the client private key, the client traffic can't be decrypted. Kind regards Paolo Brini AirVPN co-founder

Hello! It looks like some conflicting kext is already loaded. Please see here: http://code.google.com/p/tunnelblick/wiki/cCommonProblems#An_OpenVPN_log_entry_says_%22Tunnelblick:_openvpnstart_status Kind regards

Hello! It's not true for sure in Italy and some other EU countries. A court order does not have the power to make a citizen immune from committing crimes which would be implied by such an order. Additionally, such an order would presume that the VPN administrators have the technical knowledge to inspect the traffic (which is not trivial in a VPN service) and that the data they will provide are not biased or manipulated and can be accepted in a court (totally absurd). But that's anyway pure theory. A magistrate does not need that. Such an order could destroy an investigation. A magistrate for example can simply order the server to be wiretapped by the specialized police personnel or competent authority. The magistrate will very probably not even notify the VPN admins about the wiretapping, especially when such a notification might compromise the investigation. Kind regards

UPDATE: we have just received, a hour ago, an e-mail from TorrentFreak with the questions. We will reply very soon. Kind regards

Hello! Try to add: explicit-exit-notify in the list of directives inside the "Custom Configuration Box" in the "Client" (or "Client 2")->"Advanced" tab. That's because UDP is connectionless, therefore in case of disconnection without notification the OpenVPN server has no way to know that the client disconnected, so the account will be released only after the ping timeout. Kind regards

Hello! You're on the right track! Please see here for a very detailed explanation by NaDre: https://airvpn.org/topic/9787-the-pros-and-the-cons/?do=findComment&comment=11501 Kind regards

Hello! The difference is in the "nobind" directive, because the correct cipher is already set in the graphical configuration page. Therefore there's no difference if you declare nobind or not in a Tomato router when connecting in TCP mode. Kind regards

Hello! We have never been asked by TorrentFreak to sponsor them. About your 2nd question, we can't answer now, an answer should come from the Air founders collective agreement. We have never invested a cent in direct advertising. We preferred to invest very much on supporting compatible with our mission, independent projects, and on quality of service, but things of course are not immutable, and nowadays all types of investments can be no more mutually exclusive. Kind regards

Hello! An explanation comes to mind if your OS is Windows. Is it? If so, Windows lacks a proper DNS implementation. There is no global DNS and each network interface must have its own DNS. In order to send out DNS queries, svchost.exe under some circumstance may try all the DNS servers listed in every and each network card. So sometimes it might send out DNS queries to our VPN DNS, sometimes to your ISP DNS, sometimes to some other... Kind regards

Same for me, there is nothing in that page. Could you please fix that? I try ths since over a month now, the page stays empty... Hello! Page will stay blank forever, unless you subscribe your account. Access to the CG is restricted to accounts with a subscription and your accounts have no valid subscriptions. Please do not hesitate to open a ticket if you think this is a mistake. Please include your payment details. Kind regards

Hello! Sure. We're publishing the answers here, although it is supposed that those who read our forums are already well-aware about the answers to those questions. 1. No, we don't. 2. Italy. We do not share any information with any 3rd party. 3. Automatic triggering based on patterns to detect and if possible block as soon as possible various types of attacks (including UDP floods) against or from our servers. 4. They are ignored. Now and then we reply asking for a more substantiated proof and asking to disclose the technical method according to which a takedown notice has been prepared, but so far none of the entities we queried disclosed such information, in absence of which the notices pertaining to p2p are simply vague and unproven claims from some private entity. 5. No help can be given "ex ante" because we don't log, monitor or inspect our clients traffic, and we don't and can't require a proof of identity from our customers. However, if the court order pertains to presumed actions which infringe our Terms of Service and in particular that in any way violate, directly or indirectly, or aid the violation of, the ECHR, we can try to help the court in the best way we can with "ex post" investigations and if possible with the help of proper and competent authorities. 6. Yes. p2p protocols are perhaps a set of the most exciting protocols invented in the last 12-13 years, so they are actively encouraged on every server. We do not discriminate against any application or protocol, in compliance with our mission and to stay a mere conduit of data. 7. We accept Bitcoin, many credit cards, PayPal. Each payment is linked to an account in order to provide service delivery. 8. We recommend our setup, based exclusively on OpenVPN with the following features: Data Channel: AES-256-CBC Control Channel: HMAC SHA1 RSA keys size: 2048 bit PFS (Perfect Forward Secrecy): yes. TLS re-keying is performed by default every 60 minutes through DHE as well as at each new connection. The client key is used to authorize the access to the system, not to encrypt the data channel, so that even if an adversary catches the client key, the client traffic (past, present and future) can't be decrypted. Kind regards

Hello! ISPs can't see your traffic real content, origin, destination and can't even see protocols and applications that you run while traffic is tunneled. The most immediate explanation is that your system is intermittently querying (is your OS Windows?) your ISP poisoned DNS, or some other UK poisoned DNS. Use VPN DNS (10.4.0.1) or OpenNIC DNS to be sure to query non-poisoned DNS. Kind regards

Hello! Error 111 suggests that the packets are actively refused. Anyway, please consider that the test is performed in TCP only. Therefore, if rtorrent expects UDP packets the test will always "fail". Is rtorrent able to receive incoming connections while "torrenting"? Kind regards

Hello! We ALWAYS respond to ANY inquiry by private citizens, blogs, forums, etc. This year we did not receive any question from TorrentFreak, though, otherwise we would have gladly answered as we have always done. We were aware of this article only when we saw it on TorrentFreak, after publication. Kind regards

Hello! The short answer is no, because according to the document the exploit, in order to succeed to decrypt Data Channel of the VPN users, needs old IKE (as it is in IPsec basic implementation), or at least a VPN which implements a static key which is also used as the key to encrypt the Data Channel (without PFS). While these conditions can be met by several VPN services for consumers or even companies VPNs around the world, it's not our case. It's even easier in case of VoIP based on H.323, according to a comment to an article here https://www.schneier.com/blog/archives/2014/03/how_the_nsa_exp.html#comments : To say the same with different words, according to the document it seems that the attack can hope to succeed only if non ephemeral key exchange is employed by the VPN, which is not the case for a correctly configured OpenVPN system. However we are looking forward to more analysis from security teams around the world, there are some vague steps in the document which need to be explained/interpreted. Kind regards

@LBDude Thanks! At a first glance the document confirms that the attack can't succeed against OpenVPN because the foundation of the attack, at least according to the document, lies on IKE (used by IPsec and some VoIP software) packets "exfiling". Of course we will be waiting for more expert reviews and more information for a more thourough analysis. As a side note, it must be noted that approximately 11-12 years ago Schneier as well as Belani, Mookhey and many other persons reported and proved several vulnerabilities on IKE implementation, PSK etc. etc. so it's not upsetting that anyone exploits vulnerabilities when they have been well know for more than a decade. Kind regards