Staff

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

Hello! Please try to edit your hosts file to perform airvpn.org resolution inside your machine, without any need of DNS queries. See step 12 of the following guide (even if you don't use Comodo): https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 Kind regards

Hello! Please browse to our web site with any device connected to your router and check that the central bottom box is green. If you use a p2p client you can perform an additional check here: http://checkmytorrentip.com/ You can access your router web interface even when connected to the VPN in the following way: - forward a remote port on our system and remap it to local port 80 (or any local port which the router web interface listens to) - configure your DDNS to point to the exit-IP address of the Air server the router is connected to - access your router web interface directly at http://: or via DDNS (on the same port) Kind regards

Hello! This is an experimental service which works transparently, you just need to be connected to one of our servers AND use our VPN DNS. It works through multi-hopping only the strictly necessary packets in order to bypass IP geolocation based censorship. CBS is already enabled to be fully accessed from any Air server (i.e. including non-USA servers). Since the service is experimental it is not yet advertised, also if you notice problems feel free to warn us. Kind regards

Hello! "MAC Any" in Comodo rules description means "Any address" in Comodo rules definition. Please define the rule by setting in the "Type" field the "Any address" value. Kind regards

Hello! As a mere conduit we are obliged to act expeditiously to put an end to an ongoing infringement if we are notified about it. An infringement notification must exhaustively provide proofs of the infringement and in case of any possible doubt it must be verified and validated by a proper authority, even in a court if necessary. The data showed in that web site don't show any proof, no hash file verification and no technical method about the collection and processing methods (remember that collecting, processing and spreading IP addresses is illegal in some European countries, such as Italy and Switzerland, under certain conditions), they are just a curiosity which may not reflect actual infringements, see also their FAQ in which it's clear that they have no legal value in any way. On top of that, if the data are collected by querying trackers, they don't even have a statistical value, because anyone can easily send to a tracker any information (IP and port), regardless of the fact that the IPs and ports (that the tracker is notified about) are actually sharing any content. Kind regards

Hello! It's not forbidden, but in general it's not a good idea: https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea There are also ethical reasons to avoid that. The TOR network is faster than it was in the past but it's still slow on throughput under a general point of view. Relays are run by volunteers who don't earn any money with this activity and risk annoyances for abuses. If you need to receive or impart information which are very important for freedom of information via p2p, then it's ethically acceptable that you run your client over TOR. In all other cases, please consider to run your torrent client only over AirVPN, without TOR. You will have a stronger anonymity layer, higher performance and you won't consume precious bandwidth on the TOR network. Kind regards

Hello! DNS leaks are not very relevant for a torrent client. A torrent client needs to resolve trackers names (if trackers are used), nothing else. It can perfectly work, with DHT [+PEX], without any name resolution. Your Internet connectivity is not "broken", it's just that your system can't resolve names when disconnected from the VPN. So your p2p client will continue sharing. In order to allow (re)connections with the Air client, please edit your hosts file (see step 14 in our Comodo guide, even if you don't use Comodo). Binding Vuze to the tun adapter is a perfect solution to prevent Vuze to exchange any data while your system is disconnected from the VPN. That's not significant, peers in the swarm do not necessarily respond to a ping. 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

@Badgergrr Hello! Logs about 443 UDP are just fine, no packet loss or fragmentation (assuming the logs were collected after several minutes of connection). Please try different servers in order to determine the one which can give you the best performance. About 53 UDP, something is blocking/dropping packets, can you please check firewall and any other program which might interfere? Does it occur with every server? Kind regards

Hello! There's something wrong, if the allowed destination IP addresses for uTorrent are in the range 10.4.0.0/16 (10.4.0.0 / 255.255.0.0 is just the same with a different notation) uTorrent should NEVER work, regardless of your computer being connected to a VPN server or not, because that IP range is not public. You might like to install Comodo firewall (free edition is just fine). Kind regards

Hello! Can you please send us the connection logs both of the above attempted connection and of connections to port 443 UDP after some time your computer is connected? Difficult to interpret before seeing the logs, just a little hint to outbound 443 UDP port shaping by your ISP. Kind regards

Hello! If you're running the Air client for Windows, after the login please select a server (but do not click "Enter" yet), click on the "Modes" tab and select a port, finally click "Enter". If you're running OpenVPN GUI or any other OpenVPN wrapper or OpenVPN directly, please select the port(s) and protocol(s) (multiple choices are allowed) while you generate the configuration(s) in our configuration generator. Kind regards

Hello! The fact that upload bandwidth is higher than download bw does not have a definite explanation. Can you try connections to different ports (in particular 53 UDP and 80 TCP) and different servers in order to make a performance comparison? Maybe your ISP performs port shaping on UDP 443. Also, can you check in your client logs if there's packet loss or packet fragmentation when you connect to an UDP port (if in doubt feel free to send them to us after some hours of connection)? Kind regards

Hello! Currently there's no worrying indication in the new drafted data protection legal framework in the EU, while on the contrary the data retention implementation has significantly shrunk due to the implementation rejection for reasons of constitutional incompatibilities and/or violation of fundamental rights in various EU Member States (see Germany, Romania and Sweden). Additionally VPNs usage is widespread at all levels, even inside residential ISPs, and it is mandatory in many corporate environments. Of course nobody has a crystal ball to see the future, so we can't rule out completely an unprecedented attack against freedom of expression and right to privacy even inside the EU, we just can say that currently there are no apparent symptoms. Kind regards

Hello! Assuming you refer to DNS servers IP addresses, you see the DNS servers IP addresses used by our servers. Google routes the DNS queries in order to optimize performance. If you see IP addresses not belonging to Google DNS, either you are tunneling your favorite DNS through our servers or you have a DNS leak. Kind regards

Hello! Just to determine if it's a problem with outbound port 443 UDP (in your ISP infrastructure or in your system) can you please try a connection toward port 80 TCP and 53 UDP and check whether the connection is stable or not? Kind regards

Hello! IPv6 will be fully supported in the future. Kind regards