Staff

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

@clown Hello! As a side note, just a quick warning: watch your language or you will be permanently banned from writing into our forums. A DNS leak is a DNS query that's sent unencrypted (outside the tunnel) against the computer owner configuration. If your system queries a public DNS, or even your ISP DNS if it's not restricted to the ISP network, according to the owner configuration, it is not a DNS leak when: - the query is sent inside the tunnel, OR - the query does respect the system owner configuration You can query any DNS server you like from inside the tunnel. Our servers will just send your query out as they do with any other packet (no discrimination againt any protocol). The purpose of web sites like dnsleaktest is to show which DNS your system queries. The results can be used as hints to DNS leaks for further investigations. The only known system which "overrides" the owner configuration with DNS queries is Windows (due to lack of proper DNS implementation). In Windows each network card can have different DNS, simply because the concept of global DNS is totally missing since more than 20 years ago. The process svchost.exe (which is responsible for many tasks, including DNS queries), under various cases tries to send out queries to all the DNS IP addresses listed in every and each card, without regards to routing and any other configuration. Therefore web sites like ipleak.net can be very useful especially for Windows users. According to your very own description there's no DNS leak from your DD-WRT system, as it was to be expected, since DNS leaks do not affect non-Windows systems. Kind regards

We submitted a help ticket, according to the recommended method to talk with riseup.net team, about a week ago. We gave them information about our mission, a link to this topic, and informed them that we want to support riseup.net mission, with a donation and coupons for their activists. We performed the donation (1340 US $) on the same day. The day after, we received an e-mail, the only feedback we ever received: It looked like an automated reply, so we replied that we don't need any email account or any access to their services. We also entered their IRC chat and informed them that we are still waiting for a response to our ticket. No reply in a week. No further action from us is planned. Kind regards

Hello! Thank you for your feedback! We think that different business models for different needs apply here. We are the only service in the world which guarantees explicitly on the Terms of Service a minimum allocated bandwidth. It is a promise of no overselling, and we publish a real-time servers monitor to show that we respect this commitment. This makes our service extremely inexpensive, but of course only if you are able to understand the value of this commitment. Competitors are there to satisfy different needs, expectations etc.! We will always try to improve our customers' satisfaction, but we will never be able to satisfy every need of every person in the world, otherwise we would have no competitors at all. Kind regards

Hello! Where do you see that in the article? By the way, about your questions: 1 and 2. Offline access is impossible, we should be traveling around 3 continents every day and asking for infinite authorizations to access datacenters. Anyway it's not relevant, even if we did that the problem would just be the same, because there are methods to compromise a computer without having to actively operate with the computer itself, or simply because you have no guarantee that external wiretapping devices are not attached to the server a second after you leave the datacenter. The solution is completely different and we've been talking about it since years ago, please refer to https://airvpn.org/topic/54-using-airvpn-over-tor/?do=findComment&comment=1745 etc. 3.That's already performed by your OpenVPN, with double-certificate verification. During the connection, packet authentication is performed. 4. Apparently that's not relevant for us because keys are negotiated with DHE, therefore we just don't care if and who's listening to any router or any other device between your node and our node and it's not worrying not even if they catch your user.key: apart from the fact that they will be able to connect to our VPN servers with your account and therefore use our service for free, with your user.key they can't decrypt your data channel. Maybe the author of the article refers to something else (unfortunately the whole article seems to be written in too simplistic and vague terms), therefore a deeper analysis is needed. Just remember that math can't be twisted. Kind regards

Hello! Exactly. According to your very own description nowhere in the router your ISP DNS IP addresses are specified. So your router just does not know your ISP DNS. Kind regards

No problem! But what am I supposed to do now? Will that problem go away (why should it???)? Will AirVPN do something about it? Thanks for making that more clear to me! Greyzy Hello! We need to study the problem. If the web site blocks in any case multiple accesses from the same IP address it's a problem to be evaluated carefully. It's also a problem on their (n-tv) side, because nowadays NATs are used not only by us in order to provide a stronger anonymity layer, but also by thousands of ISPs due to the fact that IPv4 addresses have been exhausted since some time ago. Therefore, generally speaking, it's an idiotic decision to bar an IPv4 address because there are multiple accesses from the same IP address. It's a decision that harms the service itself. In the meantime, Wezen and Castor are still working, so you can connect them. Kind regards

Hello! No, you're wrong, they are NOT transmitted unencrypted. Anyway your user.key is useless to decrypt your OpenVPN communications. It can be used to connect to a VPN server of ours. Kind regards

Hello! We have repeatedly replied in other threads and we tend to avoid duplicates. This is a forum used by the community and you must not expect that we always enter a debate, especially if we already answered in the past. We may do it and we may not. If you want an answer on some subject from us please open a ticket at your convenience. That said, what you suggest is not a real solution, usually these block lists include entire datacenter IP ranges. What you're suggesting is to go back to full surveillance, with logging etc. and that's not what our service is aimed to. You can't claim to protect Net Neutrality, remain a mere conduit and at the same time monitor the users of your infrastructure. Anyway that would not solve the problem. As jgalt correctly wrote, the fault here is from the end service, not ours. If an abuse is perpetrated from any node of a datacenter, the maintainers of some blacklists add the whole datacenter IP range. The administrators of the services that implement such blacklists clearly prefer to be enemy of an open Internet than doing some effort to put in place more proper solutions. These administrators are the first persons to cry for Net Neutrality and freedom when their services are censored by third parties, but they are also acting exactly against the very same principles they invoke when they are harmed. In any case, preserving Net Neutrality is much more important than complying to a bad behavior of some bad behaving service administrators. Contrarily to hypocritical administrators, we struggle to remain always coherent with our mission. Kind regards