Staff

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

Hello, it's enabled by default in our service. OpenVPN works in TLS mode with TLS re-keying at each new connection and every 60 minutes. 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

Hello! Do you know what servers IP addresses that program connects to? We ask because if it connects to a definite range of IP addresses, the solution is simple, it's enough to modify the routing table, see also https://airvpn.org/topic/3024-can-i-bypass-the-vpn-with-a-browser/?do=findComment&comment=3025 Kind regards

Hello, we would have liked to know which other ISPs you noticed capping OpenVPN... Kind regards

Hello! When the program does not have a bind option the matter gets more complex. ForceBindIP (a program that through injections forces other programs to bind to an interface or an IP address) would be a solution, but it does not work properly on newest Windows 64 bit versions. In order to evaluate the best approach (if possible), can you please tell us your Windows version and which program you would need to be "un-tunneled"? Kind regards

@Royee Yes, absolutely. We have very many customers who connect their whole house or office to a VPN server via a Tomato, DD-WRT or other supporting OpenVPN firmware builds. As you can see, we provide instructions to configure both Toastman Tomato and DD-WRT ('OpenVPN-flavored') through the router web interface. One thing to keep in mind, though: consumers' routers CPU processing power is not outstanding for real time AES encryption/decryption. Our OpenVPN Data Channel cipher is AES-256-CBC. Consumers' routers CPU will be able to handle no more than 7-10 Mbit/s AES throughput, due to encryption and decryption on the fly, so the connected devices will be "capped" at that maximum TOTAL throughput. Kind regards

Hello! We don't think so, why...? Also, with the new openvpn-connect by OpenVPN Tehchnologies and our configuration generator, at least on Android 4 and higher it's actually simpler to configure OpenVPN than IPsec. For older than 4 Android versions you're right, OpenVPN installation is more complex because the device needs rooting. Kind regards

Hello! We have had some sporadic cases in which a customized network manager installed by the computer manufacturer slowed down significantly throughput on the tun/tap interface (the virtual network card used by OpenVPN). Can you please check whether the network manager is the default one by Microsoft or if it has been replaced? Kind regards

Hello! Can you please send us at your convenience the logs taken just after the problem occurs? Please right-click on the Air dock icon, select "Menu", click "Copy to clipboard" and paste into your message. Kind regards

Hello! You need to use TCP to connect to a proxy: just pick a TCP port. Socks and http proxies do not support UDP. Kind regards

Hello! Please pick any server between the other available 40. You can check anytime the servers status here: https://airvpn.org/status Kind regards

Hello! Which other providers? We have extremely rare warnings of providers unconditional shaping on OpenVPN, and in most cases they are false positives (i.e. client error, not ISP throttling). Kind regards P.S. Any other report from Virgin customers?

That's one of the reasons for which it's important to have Perfect Forward Secrecy. With a TLS re-keying at each new connection and every 60 minutes, it does not matter if somehow an adversary comes into possession of your user.key: even if that happens, your traffic between your node and the VPN server can't be decrypted. Kind regards

Hello! Migration ended, we are reconfiguring Algol and we are facing some unexpected problems. Kind regards

@phantasteek Hello! Of course, it's just fine, thank you! Also feel free to publish or send us in private the connection logs. Kind regards

Hello! We're sorry, AirVPN is based on OpenVPN. We have never received elements to assume that Virgin is throttling bandwidth against OpenVPN, did this happen recently? Kind regards

What you mean ? And why "de-anonymize" ? Hello, if you use your Skype account with AND without VPN, anybody can correlate your real IP address with your VPN IP address, due to a Skype exploit that lets anyone easily get your IP address in a few seconds . When you're connected to the VPN, they'll get the VPN IP address, when you're not, they'll get your real IP address, so they can correlate those two addresses. Additionally, if your Skype account can disclose your real identity, potentially all of your VPN activities could be correlated to your real identity by a sufficiently powerful adversary, simply because it's you the one that's giving away your identity. Skype should never be used for security and privacy purposes. Anyway if you're really forced to do so, at least never mix the same account with VPN and non-VPN connections, and never use an account that can somehow reveal your real identity (this is very difficult). Kind regards