Staff

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

Hello! We are providing and experimental service that is allowing our customers to access BBC iPlayer from any server, including servers outside UK (as long as you use our DNS), as well as USA services from servers outside USA (try CBS and Pandora). The service is still experimental so it is not advertised, except in the servers status monitor where you can see "Micro" servers that are used to bypass IP geo-location based censorship. Kind regards

Hello! Apparently the URL you're inserting in the torrent client points to a .torrent file which can't be located anymore by the destination server. What if you try to access the URL from your browser (still while connected to a VPN server)? Kind regards

Hello! Of course. Kind regards

Hello! Yes, we are, although we can't satisfy all the massive amount of requests. Free access is anyway guaranteed to activists working in human rights hostile countries according to our bandwidth availability. The quickest way to obtain a trial access is subscribing to any plan, testing for 3 days and before the end of the 3rd day asking for a refund (no questions asked) if the service does not meet your expectations and requirements or if you prefer to change plan. Refunds are normally delivered in a few business days and in any case never later than 30 days. Preserve your invoice ID or transaction ID and send it to us if you ask for a refund so that we can correlate the payment to your account and deliver the refund swiftly. Kind regards

Hello! Please see here to prevent DNS leaks on Windows: https://airvpn.org/index.php?option=com_kunena&func=view&catid=2&id=7462&limit=6&limitstart=6&Itemid=142#7529 Kind regards

Hello! Apparently there's some very basic misunderstanding. When your computer connects to an Air server it is inside a Virtual Private Network. All the communications between your physical network card and the VPN server occur through one single outbound port and one single inbound port. The real headers and payloads of the incoming packets are still encrypted when they pass through the router and they are still encrypted when they pass through your computer physical network interface. They are decrypted by your computer OpenVPN client only on the tun interface. The real headers and payloads of the outgoing packets are already encrypted when they pass through your physical network interface and your router. They are decrypted only when sent out by our servers. Therefore: - the real headers and payloads are visible only on the tun interface - your router, as well as your computer physical interface, sees only traffic from/to one single IP, one single outbound port and one single inbound port, regardless of applications, protocols, real origins and real destinations of the packets - the incoming packets are routed to the real destination port only after they have passed through your computer interface - the outgoing packets are routed to the real destination IP and port only after they have passed through our servers various interfaces Our remote port forwarding allows a remote forwarded port to be remapped to a different local port (see previous message and instructions on our web pages). Your p2p client notifies the tracker(s) (if any) with the listening port you have configured in it. Considering all of the above, it should be now clear to you that in order to achieve what you want: - you must NOT remap a remotely forwarded port to a different local port - you must set on your p2p client the same port that you have remotely forwarded - you must not worry about forwarding ports on the router, just keep them all closed (or at least make sure that the remotely forwarded ports are closed on your router to prevent correlation attacks) ONLY respecting ALL the above conditions your client will report to the tracker the correct port (so your tracker stats are ok), your client will be able to receive incoming packets and your anonymity layer will not be vulnerable to correlation attacks. Actually, Vuze provides also a useful bind feature which will prevent any correlation attack even if your router is badly configured and will also prevent leaks of your real IP address in case of unexpected VPN disconnection: just bind Vuze to the tun interface. Kind regards

Hello! We have been notified that Cogent Communications is having problems with a router and a fiber cut. Cogent is a tier1 provider of Virginis datacenter in Bern. As a consequence (from Cogent Communications): While Cogent works to solve the problems (as you see, no ETR is possible), we recommend our customers from Spain, France and Mexico not to use Virginis. Kind regards

Hello! For your purposes, do NOT remap on our system a remotely forwarded port to a different local port and make sure that the torrent client listening port matches the port number you have remotely forwarded on our system. If you use a DD-WRT / Tomato / OpenWRT router which runs an OpenVPN client which connects to an Air VPN server, then enable DNAT on the router to forward the same port to the machine where the p2p client is running. If you don't use a DD-WRT / Tomato / OpenWRT router, or anyway if you don't establish a connection from an OpenVPN client running in the router but you establish it from the same machine where the p2p client runs, do NOT open the remotely forwarded port(s) on the router (doing so exposes you to some correlation attacks). Kind regards

Hello! Check "obtain DNS servers automatically". Kind regards