Staff

Hello! The web site ipleak.net is under maintenance since 2 days ago (not 3 or 4) because it needs maintenance (a bug must be resolved). It will be available again when the maintenance is over. We have no idea why nobody else offers alternatives, ask anybody else. Kind regards

Hello! The web site is under maintenance since 2 days ago because it needs maintenance (a bug must be resolved). It will be available again when the maintenance is over. Kind regards

Sorry, but I couldn't understand this. I'd run an application that requires ( for example let's say Port 3985 which I forwarded from the client area ), it has to be open first .. then I can run the application. Hello! It's exactly the opposite. "A port" is a task or process specific software construct (an abstract concept in some way) to designate the communication end-point of that task or process in the host system. This end-point allows the system to identify the correct task or process which the data are directed to. In TCP/IP for example a port is identified by two bytes in the header (that's why port numbers range can't exceed 65535). If no task/process with a certain end-point is running, that end-point of course does not exist, and "the port" simply does not exist in your system. When you perform a test, if the service is not running your system will have no task/process to send the packet to and there will be no reply at all. Kind regards

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