Staff

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

Hello! Ok, so there's no subnet conflict. Also, the logs are just fine, however there's apparently something very wrong in the routing table. Are you behind a proxy? Kind regards

Hello! So, if we understand it correctly, sometimes it works and sometimes it does not. In this case, it's a symptom of some TCP/IP stack problem (and perhaps also Winsock problem), further suggested by that very suspicious "General failure" error in the ping output in your previous message. If the problems persists, it is usually fixed by a TCP/IP and Winsock reset followed by a system reboot, 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, stay tuned! There was some long delay but in the end the server we paid 5-6 weeks ago is almost ready to be configured. We will probably be able to start configuring it in less than a week. Configuration will take just 10-20 minutes, after that we'll keep the server on testing mode for a couple of days, and finally, if everything goes well, we'll announce it and put it public. Kind regards

Hello! You're doing everything just fine, it's OpenDNS that's messing up the whole thing. Look at this log line: Take note of that 67.215.66.146 IP address. It's the IP address of a server to which OpenDNS hijacks users when a domain name is non-existent (according to OpenDNS...). So, OpenVPN correctly asks for america.vpn.airdns.org resolution, your system queries OpenDNS, and OpenDNS returns its own server IP address (because it very wrongly "assumes" that *.airdns.org does not exist). This is passed back and OpenVPN tries to establish a VPN connection to an OpenDNS server (!), which obviously fails. You have two options to solve the problem: 1) get rid of OpenDNS (use for example OpenNIC http://www.opennicproject.org or any other public DNS you like), you might like not to use a DNS that hijacks you. In this case the hijack has caused you some minor trouble and waste of time, in other cases it might cause more serious troubles. OR 2) re-generate the OpenVPN configuration file(s) ticking "Advanced Mode" and "Resolved hosts in .ovpn file" in the Configuration Generator. In this way the CG will not insert names in the .ovpn file, but only IP addresses, solving the problem at its roots. Kind regards

@tunica Hello! It's clearly a problem in the Windows firewall as you correctly found out. Can you please make sure that the VPN network is not blocked in any way? It must be a trusted network. Warning: Windows firewall, for some inexplicable reason, bizarrely calls a network in which you potentially might wish to receive incoming connections as "Home network". See also here for more references: http://superuser.com/questions/44503/how-do-i-tell-windows-7-to-trust-a-particular-network-location Kind regards