Staff

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

Hello! Can you please send us your client logs? Kind regards

Hello! Both network cards replacement have solved the issue. Tests in the last 6 days have been fully successful. Kind regards

Hello! A part of the team is working to provide OpenVPN over SSL and OpenVPN over SSH directly in our infrastructure in a very near future. This solution should let you connect to our servers even when OpenVPN connections are disrupted. Furthemore, if your ISP decides to block access to airvpn.org, we have very many solutions to circumvent the censorship, write to us at info@airvpn.org if/when you need them. Kind regards

Hello! Quite puzzling... either your ISP tries to block TOR intermittently, or there is something here that we're missing. Does OpenVPN to port 443 TCP connections continue to fail? Can you try a connection over a publick SOCKS proxy with your browser? Instructions for Firefox: http://www.wikihow.com/Enter-Proxy-Settings-in-Firefox Unverified list of available socks proxies (do NOT use them to send or receive sensitive unencrypted data, this is just for testing purposes): http://sockslist.net Please try proxies which accept connection to port 80 and 443, if they fail proceed to test proxies on different ports. Kind regards

Hello! So it appears that also TOR is disrupted by your ISP. Before proceeding further, can you please check that your system date and clock are correct? TOR needs an accurate timing to establish a circuit, and OpenVPN may fail TLS authentication as well if your system date is not correctly set. Please send us also the TOR logs to verify. Kind regards

To sum up all the previous replies... A VPN provider may correctly claim that remote port forwarding ON ITS SYSTEM lowers security if its system is badly configured (same shared entry-IP and exit-IP). In all other cases, a breach in the anonymity layer can come only from bad behavior of the customer, regardless of remotely forwarded ports or not. Obviously the security patch of a lazy provider would be not to provide remote port forwarding options at all. This would also solve the problem of services which are run behind a VPN server. Since we strongly want to remain on our role of mere conduit, we have walked a completely different road, leaving total freedom to our customers whether to use or not remote port forwarding, and protecting the customer anyway in the best technical possible way if he/she decides to forward ports. We don't take into considerations wrong behaviors of the customers which in any case can't be prevented and that are not strictly related to remote port forwarding: a VPN can't secure in any way a customer wrong behavior. There's nothing a VPN provider can do, just to make an extreme example, if a customer logs in a service with an account bound to his/her real name or willingly sends out identity disclosing information while connected to a VPN, or in general if the customer mixes up VPN identity and real identity. Kind regards

Hello! Probably the claims of the providers you cite refer to a particular case of the wider 'identity-separation" issue. In the p2p field, if you connect to a swarm both when connected and disconnected to the VPN, and the torrent client always listens to the same port, you leave a hint (in most cases, totally useless) that a client using a VPN server is the same client that you used when not connected to the VPN. There are much more significant cases where using the same identity behind and not behind the VPN can expose to much stronger correlation attacks. A typical, even though stupid, example is when you log in a web site with the same account both when connected and not connected to the VPN. No, as long as you have a green token, a performance difference should be noted only during the initial time needed by the torrent client to punch the NAT (in order to punch it, it needs help from other peers, so you might experience some minutes delay during which the token stays yellow and the client is unable to receive incoming packets). It's difficult to notice them. The adversary must have the ability to monitor your line. In that case, the adversary may notice that you're connecting to a VPN server. It must also be able to understand that the IP address you connect to belongs to a VPN server which sends out your packet from a different IP address (the exit-IP of our servers), so it must also know this feature in our system. Once the adversary has got all these information, he/she can try to send packets to all ports of the VPN server exit-IP address and notice which packets receive a reply. After that, the adversary must send, to the very same ports, packets to your real IP address. If he/she receives an answer on some port from your real IP address (assuming that your system is misconfigured, i.e. you have opened in the router the same ports that you remotely forwarded on our system), the adversary has a hint that the very same service responding to the same port on the VPN exit-IP is yours. At this point, the adversary can collect more evidence by performing timed packets sending toward the same ports on the VPN exit-IP and on your real IP address. Other types of correlation attacks are not possible. They would be possible only if the VPN server had the same entry and exit-IP addresses, in which case the adversary would have an additional, significant option to perform an attack from inside the VPN: two clients connecting to the same VPN server and exchanging packets between each other would exchange those packets unencrypted OUT of the tunnel (this is due to how a VPN works), immediately allowing the attacker to discover the client real IP address, without even the need to monitor your line. This a typical vulnerability of all VPN services which send out your packets from the same IP address your clients connects to, i.e. all VPN services which don't have separate shared entry-IP and exit-IP addresses (and there are many 'out there'). Yes, if configured according to our guide, Comodo will doom the aforementioned attacks to total failure even if your router ports are open, because no service will ever be able to send packets outside the tunnel in response to an incoming packet to your real IP address. However, in an environment where exit-IP and entry-IP are the same (which is not the case in our service: in addition to separate entry and exit-IPs, no packet with entry-IP as destination IP is forwarded to any client VPN IP address, i.e. no packet with destination the entry-IP is ever forwarded to VPN clients) those rules will be impotent against the other type of attack above mentioned. Kind regards

Hello! Yes, they count, so it is a hint that only OpenVPN connections are disrupted (assuming that you have already ascertained that connections toward port 443 TCP do not succeed). Next step, are you able to use TOR? Are you able to connect some application (try your browser, but do not use a socks proxy to send or receive unencrypted sensitive data) over some socks proxy? Kind regards

Hello! Ok, so let's determine whether your ISP disrupts OpenVPN connections through Deep Packet Inspection. OpenVPN fingerprint is slightly different from a "classic" SSL/TLS connection and this difference can be exploited to discern, via DPI, OpenVPN connections from (for example) https. Are you able to connect to https web sites? Kind regards

Hello! Ok. Before anything else, do you know whether you are behind a proxy? Kind regards

Hello! Technically it works via a 'DNAT'. Packets reaching a remotely forwarded port on our servers exit-IP addresses are forwarded to the correct VPN IP:local port of the client. Security risks may come from correlation attacks. Prevent them by NOT opening on your router the same ports you have remotely forwarded (or just apply the firewall rules to prevent any leak according to our guides - they will also prevent any correlation attack based on port forwarding). For latest uTorrent versions and any other torrent client that can successfully 'punch' a p2p-friendly cone-NAT, remote port forwarding is not strictly necessary, not even for performance. Kind regards

Hello! Are ALL the Allow rules placed higher than the "block all" rule? Also, at least one rule seems to be missing (see step 11a). See also step 12 in case you forgot to modify your hosts file. See step 11 to allow communications with your router and with your internal network. Please feel free to send us a screenshot of your Global Rules and Network Zones, and the content of your hosts file. Kind regards

Hello! As a general rule, a so-called Internet Service Provider which does not provide Internet access should be left without customers. These crooks survive because they are allowed to be called "Internet Service Provider" even though they don't provide Internet access but above all because people continue to give them money. That said, first of all try connections to all available ports (53 UDP, 53 TCP, 80 UDP, 80 TCP, 443 UDP and 443 TCP) and let us know whether a connection can be established to one (or more) of them. Kind regards

Hello! If you're absolutely sure that nothing in your system and internal network can block outgoing packets to outbound port 53 UDP, and given that it happens with all our servers, the only remaining option is that your ISP drops those packets (probably except toward its own DNS). Kind regards I don't really understand this? What else in my system would block outgoing packets? Hello! You might try to discover it by disabling any single program that might interfere with connections and try a connection each time you disable one of those. No, not necessarily, it depends on the port shaping (if any) performed by your ISP. You might like to inquire your ISP in the first place, in order to understand if the block comes from it or not. Try different ports, protocols and servers, for each of them perform an internal speed test http://speedtest.air in order to determine the server, port and protocol which can give you the best performance. Kind regards