Staff

Hello! Yes, it's normal. The Unidentified network is bound to the TAP-Win32 Adapter (the virtual network interface used by OpenVPN), as far as we can see from the screenshot, because the reported IP address is the VPN IP address DHCP-pushed to your client by our servers. Kind regards

Hello! Not really... HTTP is TCP traffic, while torrent clients rely heavily on UDP. UDP over UDP has some advantages (for some purposes) and disadvantages on UDP over TCP. There's also at least another variable to take into consideration, i.e. with http you normally connect to a single server, while with p2p to a swarm of peers. Kind regards

Hello! Yes, it's possible, the performance difference may be very small in optimal conditions (for example when your ISP is directly connected to, or IS, the same tier1 provider to which the Air server is connected to). What is your ISP nominal "peak" download bandwidth? Kind regards

Hello! The upgrade solved the first detected problem. Now the logs look just fine. Kind regards

Hello! The problem is that the TAP-Win32 interface does not come up properly. Can you please try an upgrade to OpenVPN 2.3.0? Please pick the package for your system here: https://airvpn.org/windows OpenVPN 2.3.0 fixes several issues with the TAP-Win32 driver for Windows. Kind regards

Hello! Perfect, Transmission is correctly tunneled as expected. Kind regards

Hello! The reason of the disconnection is that there's no communication between your system and Castor. Maybe it happens 2-3 times a day. See here: and here: Our configuration files already order OpenVPN to retry connection. network-manager ignores also "explicit-exit-notify" directive (so even when the client disconnects "cleanly" our servers do not get notified of it by the client). Can you please try a connection directly with OpenVPN to make a comparison test? Kind regards

Hello! Apparently there's a communication problem between your system and the server you're trying to connect to (unfortunately you deleted the IP address so we don't know whether you're pointing to the correct address). Can you please check that your firewall or any other program is blocking OpenVPN and/or UDP packets to outbound port 443? Do you get those logs with every server on port 443 UDP you try to connect to? Have you tested different ports? What is your OS and which client are you using? If it's network-manager, please make sure that you generate (in our configuration generator) .ovpn configuration files NOT embedded with certificates and key, because unfortunately network-manager does not support them. Kind regards

Hello! Can you please perform the following test (while you're connected to an Air VPN server): http://checkmytorrentip.com and check whether the test detects your real IP address or not? Kind regards

Hello! No, the DNS servers used by our servers (after a first, internal resolution to bypass ICE censorship) are by Google, which routes the query in order to optimize performance. If you see only Google DNS you have no DNS leaks. Kind regards

Hello! In order to show the routing table issue the command (from a shell): netstat -rn or netstat -r if you wish host names. Which torrent client are you running? Might it be forced to bind to your physical interface, instead of tun adapter? For example Vuze provides a bind option. Kind regards

Hello! At the time of your writing we had approx. 15 "tormented" minutes caused by db lack of sync. The problem was solved, please feel free to let us know if it's all right now. Kind regards

Hello! When the problem occurs, could you please try to close the Air client, open a command prompt, issue the command "ipconfig /renew", re-launch the client and connect again? Can you please let us know if these steps solve your problem when it occurs? Kind regards

Hello! Nothing seems unusual, all the data you report do not show anything strange. About the routing table, which OS are you running? Kind regards

Hello! In optimal conditions UDP is much more efficient than TCP for an OpenVPN connection. Please see our FAQ for more details. https://airvpn.org/faq#udp_vs_tcp Kind regards

Hello! Either you're not really connected to an Air server or your account in the chat room has been recorded with your real IP address (maybe you connected to it in the past with your real IP address and the same account). In order to ascertain that your VPN connection is correctly established, can you please send us your client connection logs? Kind regards

Unfortunately, DNS was originally designed with a great deal of implicit trust, so encrypting the traffic between you and AirVPN doesn't necessarily cure everything. https://en.wikipedia.org/wiki/DNS_spoofing Hello! It must be said that connection to Air makes your system immune to DNS spoofing as long as you use the VPN DNS (and you don't have malware or hosts interfering software rewriting your hosts file, but in this trivial case neither DNSSEC can save you, obviously). And it must also be noted that things like that can't happen AFTER the connection to an Air VPN server (of course China has still the power to perform IP hi-jacking against our servers IP addresses and prevent connections or cause disconnections to our Chinese users). Kind regards

Hello! Glad to hear it. Some things to check on Comodo: - logging: an excessive logging may slow down the whole system - in the "Advanced" tab of the "Firewall Behavior Settings", the following items must NOT be selected: "perform protocol analysis" "block fragmented IP datagrams" and finally probably the most important thing to check: make sure, when you're connected to the VPN, that no task/process is flooding Comodo with an attempt to send packets outside the tunnel (even if they are not harming because directed within your private network, typical example Windows system tasks which start sending an incredible amount of packets toward broadcast addresses under rare conditions). You can check that on the "View Active Connections" windows or even better in the Comodo logs (if you enabled logs for the Block rule(s)). Kind regards

Hello! The MTU in Air is the OpenVPN default (1500 bytes). The fact that your setup does not work in any case (with or without connection to an Air server) suggests that there's something wrong in your freenet configuration. Kind regards

Hello! Please make sure that you have no "defense" program which might wrongly identify UDP packets as an attack and subsequently start to drop packets. When you connect over OpenVPN, all the packets come from the same IP and port on your physical network interface, regardless of the real protocols and applications you use (as you know): the real headers and payload are still encrypted when a packet arrives to your physical network card (the decryption occurs later, when the packets are on the tun adapter they are already decrypted). Having a massive amount of UDP packets all coming from the same IP and toward the same inbound port may trigger a flood alert for some firewall or network monitor/packet filtering programs. Kind regards

Hello! The problem is here: Probably something went wrong during the installation of OpenVPN. Please try to add a TAP-Win32 Adapter by going to "Start"->"All Programs"->"OpenVPN" and launch "Add a new TAP-Windows virtual ethernet adapter" with administrator privileges. After that, try again a connection, if you still have problems do not hesitate to send us the logs again at your convenience. Kind regards

Hello! The attack is ineffective against OpenVPN for various reasons: - the attack is faster with DTLS, which is not used by OpenVPN - in absence of DTLS, the attacker needs to send the same plaintext secret on thousands of different connections to the same server; in order to do so, aid of cookies, javascript injection and usage of a browser by the victim is mandatory, all requisites which are not met by OpenVPN - the attack in absence of DTLS requires a considerable time, superior to the the TLS keys re-negotiation OpenVPN time (60 minutes by default, and you can also lower it on the client side) - if an adversary has the power to inject forged packets in an OpenVPN connection, and even if the attacker were able to pass the OpenVPN HMAC verification, tunnel authentication renegotiation is started again by OpenVPN It is relevant that the researchers who invented the attack (a variant of a previous, well-known attack to which OpenVPN is immune) did not cite OpenVPN in their paper, their attack was based, in absence of DTLS, essentially against https, because without cookies and javascript injections it is practically impossible to perform a successful attack. Of course we will be following closely the developments, in case the attack is enhanced. About our https website, using RC4 (fully supported by our web server) greatly mitigates the risks, and anyway you can connect to our website via TOR or via OpenVPN to stay absolutely safe. References; http://www.imperialviolet.org/2013/02/04/luckythirteen.html Kind regards

@mavham Hello! The [AIRvpn server addresses] network zone is wrongly defined. It must include the entry-IP addresses (not the exit-IP) of the Air servers you wish to connect to. No OpenVPN clients connections are allowed on the exit-IP. If you have issues in finding the entry-IP addresses with our configuration generator, please do not hesitate to contact us in private (menu "Support"->"Contact us"). Kind regards

Hello! There's only a screenshot of the content of the hosts file, anyway it might be enough. The '#' symbol at the beginning of a line in the hosts file means that the line is commented out. It will not be evaluated. Therefore, please edit again the hosts file, delete the '#' symbols on the lines pertaining to airvpn.org and save the file. Kind regards

Hello! Apparently the problem is in your hosts file, the line should be: 85.17.207.151 airvpn.org If the above does not solve your problem, can you please send us a screenshot of your Comodo Global Rules and the content of the hosts file? Also, please note that the hosts file in Windows 7 is normally in :\Windows\system32\drivers\etc Kind regards