Staff

Hello! The "No route to host", code 65, may be caused by a line drop or a null-routing of the destination IP address or a firewall in your system that drops packets (for example when it sees "too much" UDP flow). Please see here (about Tunnelblick): http://code.google.com/p/tunnelblick/issues/detail?id=120 and here (about SparkLabs Viscosity): http://www.sparklabs.com/forum/viewtopic.php?f=3&t=1227 We can't verify the logs on the server side because OpenVPN logs are sent to /dev/null according to our policy. Try to connect to a TCP port to see whether the problem gets solved or not, which may be a precious hint. Kind regards

Hello, because the traffic is still encrypted by your OpenVPN 'client' when it passes through the TOR nodes. It is decrypted by our VPN server and then sent out on the Internet. Remember that OpenVPN has the ability to connect to a VPN server over a socks or an http proxy. Example for outgoing packets: your cleartext packets headers and payloads are encrypted and then encapsulated in TCP or UDP by your OpenVPN. Before getting out of your system, they are again encrypted and encapsulated by TOR. When they reach the TOR exit-node, only the encryption layer by TOR is no more. The OpenVPN encryption is still there. See above. Yes, this the solution. It introduces other problems (see http://forum.dee.su/topic/vpn-tor-more-anonymity) so you must evaluate the purpose of this solution. The main purposes are solving the TOR exit-node problem you cited, hiding your IP address to our VPN servers (partition of trust, to defeat an adversary that's wiretapping a VPN server) and hiding to the final node (but not to your ISP!) the fact that you're using TOR. Additionally, this is a "starting point" for more sophisticated forms of partition of trust. Imagine for example to connect a host over OpenVPN over TOR. Then run a Virtual Machine in that same host and connect to a VPN service, or to TOR, or to another proxy, that VM (itself connected via NAT to the host machine). You will have an additional partition of trust which might be desirable in extremely critical data transfer, when low performance is considered an acceptable price to pay. Kind regards

Hello, side note: in 2010, when AirVPN was being born, we discarded PPTP (that was an obvious choice) and after a careful evaluation we picked OpenVPN and discarded IPsec as well. There are even additional considerations about IPsec, on top of those that you have kindly reported, which convinced us to prefer OpenVPN. Kind regards

Hello! Please see the above link on partition of trust. Even if we said (and beware, we're not claiming that) that this can't happen with our system and our providers, you would anyway have to trust us and we would anyway have to trust our provider. With partition of trust, you distribute trust between N parties, so that if N-1 parties betray the trust, your anonymity layer is NOT compromised, effectively solving the trust problem in a drastic and effective way. We faced this problem in 2010, at the birth of AirVPN. Kind regards

Hello! It does not matter at all, just use lynx. Most of our site pages are perfectly readable in text mode. And the menus are perfectly selectable without a mouse and a pointer. Example: lynx https://airvpn.org/status No, it's the DNS record that is updated (if necessary). OpenVPN will not disconnect without a command from you. Yes, please generate a file with the remote-random directive in the following way: - click "Advanced Mode" - tick "Resolved hosts in .ovpn file" - tick "All servers for area or region" In this way a configuration file that will cause OpenVPN to rotate randomly (at each connection) between all the servers of the selected area will be generated (for this operation: yes, you will need a graphical environment - then upload the configuration to your server). Kind regards

Hello! No, it wouldn't be compromised. If someone in any way could get in possession of your user.key, it could NOT decrypt your tunneled traffic. See also https://airvpn.org/topic/9949-us-and-uk-spy-agencies-defeat-privacy-and-security-on-the-internet in order to know why. That said: PKCS#12 is not currently supported. Kind regards

Hello, thank you, unfortunately that web site requires registration to read the link you provided and currently registrations are closed, but we'll keep an eye on it just in case they re-open registrations. Kind regards

Hello! Yes, it's an additional encryption layer. Unnecessary as you said, if the magic of the attacker could decrypt OpenVPN ciphers before we're all dead, instead of million of years, the additional SSL would be no match as well. Kind regards

Let's continue here (this forum section is not the proper place, for clarity purposes): https://airvpn.org/topic/9958-importance-of-partition-of-trust-for-critical-data-exchanges Kind regards

Hello! Yes, only physical servers. Your report is important, what is the Dutch provider? Do you have any additional reference to the case? And of course nobody can be 100% sure that a sufficiently powerful entity wiretaps your machinery, regardless of any kind of service or provider, not even if you run your own datacenter. Encrypting the OS on the server is not a solution, because the adversary can put two boxes on incoming and outgoing connections and correlate any traffic flow simply through timing (similarly to any timing correlation attack in any low latency network). Also see the importance of partition of trust, strictly related to the issue (and capable to defeat the aforementioned adversary, provided that this adversary is not also capable to monitor at the same time the relevant TOR circuit you have established or the external service you have picked - an extremely low probability): https://airvpn.org/topic/54-using-airvpn-over-tor/?do=findComment&comment=1745 Kind regards

Hello! We don't use VPS or cloud servers for our VPN servers. Kind regards

Hello, currently there are more than 300 VPN services out there that actually offer a low security service. Just think of PPTP with MS-CHAP v1 or MS-CHAP v2 or MPPE authentication: cracking it is relatively easy and does not even require NSA capabilities. Then think about VPN services that run OpenVPN configured in Static Key Authentication mode. Obtaining the static keys in any way (sometimes it might be enough to just ask...) would give immediate capability to decrypt all past (if captured), present and future data streams. So the alleged purpose does not seem unrealistic at all. Kind regards

Hello! You can't change your user.key on your own. Please feel free to open a ticket if you wish to do so. No, it's not planned for 2013 because it's not necessary (on top of that, OpenVPN 2, 2.1 and 2.2 do not support natively ECC). It would require a massive conversion of all of our clients for nothing: we don't use SHA1 for packet encryption or authentication. We use HMAC SHA1 for packet authentication, which is a totally different beast. In order to try to find hash collisions in an attempt to inject forged packets, an attacker should first break HMAC to reach the underlying hash algorithm. Kind regards

https://airvpn.org/topic/9949-us-and-uk-spy-agencies-defeat-privacy-and-security-on-the-internet Kind regards

Hello, we need to create a FAQ for this! In the meantime please see here: https://airvpn.org/topic/9949-us-and-uk-spy-agencies-defeat-privacy-and-security-on-the-internet/ Executive summary: the answer to your question is yes. Kind regards

@degas432 Yes, we're saying that, but we're saying even more. We're also saying that if (just to make bad science fiction, because all the elements point to the contrary) NSA could break the encryption for ONE of your keys AND discern AND capture the packets stream of a client for THAT key, it could decrypt ONLY the packets stream included in the time frame between two TLS re-keyings (see also on Wikipedia "Perfect Forward Secrecy"). An interesting discussion is here http://crypto.stackexchange.com/questions/579/how-can-we-reason-about-the-cryptographic-capabilities-of-code-breaking-agencies one paragraph of one of the posts is particularly worth to be quoted. It's one month old but it was prophetic in light of the most recent leaked documents: Reading the slides for PRISM the cost of the program is way too low to include any sort of computationally intensive pursuits. It's not a far leap to infer PRISM being a key sharing effort. Several accounts seem to indicate the NSA are actively subverting security on the standards level or in collusion with software developers. If either proposition is true, any serious cryptographer needs to use systems where every component is known and excludes closed source operating systems and software black boxes. One side note as a figurative example: being worried about NSA decrypting your one-hour AES-256 traffic while at the same time running Windows is like being worried exclusively about an asteroid hitting your head when you walk at night alone in San Pedro Sula while happily waving 10000 dollars in your hand. Kind regards

Hello! Actually we had never met this problem before (at least it was not in the knowledge base). As a coincidence, we had two more customers who had this very same problem with Windows 8 just a few hours ago, one of them solved it just with a TCP/IP stack and Winsock reset ( https://airvpn.org/topic/9946-no-connection-on-win-8-w-airvpn-client/ ). In order to perform the reset please see here: https://airvpn.org/topic/8320-solved-connects-but-ip-doesnt-change-on-windows-server-essentials-2012/?do=findComment&comment=8321 Kind regards

Hello! Yes, it's planned. You're correct, some servers are using that version. Some servers have been already updated to 6.0p1, which is the version in latest Debian stable, Wheezy, if we're not mistaken. We'll check with the relevant persons (access to VPN servers is restricted for security reasons, only Air founders have full access to them). Kind regards

Hello! You can't without interrupting OpenVPN. Install "screen", launch a screen and run OpenVPN from inside the screen. Detach the screen by pressing CTRL+A, then pressing D ("D"etach). You can resume the screen with screen -r You can see the screens list (you can open as many screen as you wish) with screen -ls See "man screen" to get full advantage of this powerful tool. Every 300 seconds the control system performs many measurements then inserts observed parameters (such as latency between every node in the designated area, available bandwidth, packet loss, servers status and more) in a formula which returns a score. The higher the score, the "healthier" the server is. The server with the highest score is the "best" server. The domain name record for that zone is then updated, if necessary, to resolve to the entry-IP address of that best server. TTL is 5 minutes. You can anytime see the best server for every area in the right tables of the servers monitor (click "Status" from the upper menu). A graceful kill is recommended. Do not kill the screen in which OpenVPN is running, because in that case OpenVPN would be prevented to notify our servers of the disconnection (causing a 60 seconds delay in account unlocking if the connection is over UDP: being UDP connectionless, the server has no way to acknowledge a disconnection, so it will consider the client disconnected only after the ping timeout). Additionally, a non graceful kill can prevent OpenVPN to restore your system previous routing table. You can gracefully kill OpenVPN with a simple kill command, or by pressing CTRL-C from inside the screen where OpenVPN is running. Kind regards

Hello! Please note that the VPN DNS servers IP addresses are wrong, the correct ones are: 10.4.0.1 10.5.0.1 Kind regards

Hello! It seems just fine, your name (which is not x.airdns.org, please check) correctly resolves to the exit-IP address of the server you're currently connected to (even with Google DNS). Kind regards

Hello! It seems that your system DNS can't resolve america.vpn.airdns.org. Can you please tell us which DNS is used? In order to solve the issue, re-generate the configuration file(s) in the following way: - tick "Advanced Mode" - tick "Resolved hosts in .ovpn file" - tick "All servers for area or region" In this way the Configuration Generator will generate configurations with IP addresses only (no names) solving the problem at its roots. Alternatively, try to change your system DNS. Kind regards

Some additions in order to be more precise: You can lower the re-keying time, if you wish so, with the directive reneg-key to be inserted in the .ovpn configuration file (note: this option is not available in the Air client, you'll need to run OpenVPN GUI or OpenVPN directly). You can NOT increase the re-keying time (3600 seconds), because that would need a modification on server side configuration. If you do so, your connection will be lost after the first 3600 seconds. We use "method 2": In method 2, (the default for OpenVPN 2.0) the client generates a random key. Both client and server also generate some random seed material. All key source material is exchanged over the TLS channel. The actual keys are generated using the TLS PRF function, taking source entropy from both client and server. Method 2 is designed to closely parallel the key generation process used by TLS 1.0. Note that in TLS mode, two separate levels of keying occur: (1) The TLS connection is initially negotiated, with both sides of the connection producing certificates and verifying the certificate (or other authentication info provided) of the other side. The --key-method parameter has no effect on this process. (2) After the TLS connection is established, the tunnel session keys are separately negotiated over the existing secure TLS channel. Here, --key-method determines the derivation of the tunnel session keys. Please see the OpenVPN manual for more details. Kind regards

Some additions in order to be more precise: You can lower the re-keying time, if you wish so, with the directive reneg-key to be inserted in the .ovpn configuration file (note: this option is not available in the Air client, you'll need to run OpenVPN GUI or OpenVPN directly). You can NOT increase the re-keying time (3600 seconds), because that would need a modification on server side configuration. If you do so, your connection will be lost after the first 3600 seconds. We use "method 2": In method 2, (the default for OpenVPN 2.0) the client generates a random key. Both client and server also generate some random seed material. All key source material is exchanged over the TLS channel. The actual keys are generated using the TLS PRF function, taking source entropy from both client and server. Method 2 is designed to closely parallel the key generation process used by TLS 1.0. Note that in TLS mode, two separate levels of keying occur: (1) The TLS connection is initially negotiated, with both sides of the connection producing certificates and verifying the certificate (or other authentication info provided) of the other side. The --key-method parameter has no effect on this process. (2) After the TLS connection is established, the tunnel session keys are separately negotiated over the existing secure TLS channel. Here, --key-method determines the derivation of the tunnel session keys. Please see the OpenVPN manual for more details. Kind regards

On top of that, this is an answer given on some tickets a few minutes ago, as a reply to worried inquiries following the new articles on The New York Times and other publications. Hello! [Looking deeper into papers and more technical articles, already available] NSA can decrypt only encrypted data for which NSA already has the keys (through back doors or just by getting the keys) or for weak, obsolete ciphers. That's why it's very important to use services (like ours ) which do not possess your key and comply to Perfect Forward Secrecy. For example, when your OpenVPN client establishes a connection to one of our servers, a new TLS key is negotiatied (Diffie-Hellman/Perfect Forward Secrecy) AND and a new TLS re-keying occurs every 60 minutes. Additionally, AirVPN is based on OpenVPN, which is free and open source, and have been and is being under intensive crypto-experts peer-reviews since its birth more than 10 years ago. No backdoor has ever been found. We run OpenVPN with the following ciphers: OpenVPN Data Channel: AES-256-CBC OpenVPN Control Channel: HMAC SHA1 RSA keys: 2048 bit size OpenVPN in TLS mode (Perfect Forward Secrecy: re-keying at each connection and re-keying every 60 minutes) Now let's assume that NSA (or any other very malignant adversary) breaks into your system or into our secret backend servers and obtain your user.key (the user.key is not kept in the VPN servers, and the location of the backend servers is unknown to everyone except the Air founders; the clients and the VPN servers never communicate directly with the backend servers). Now, the user.key is used to authenticate your client, but the TLS key is re-negotiated. So NSA or that malignant entity could use our VPN with your account, assuming that they get also the certificates (so they can save 7 EUR a month and get a free ride with our service ), but it would not be able to decrypt your communications with our servers. Kind regards