Staff

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

Hello! It's already pushed by the OpenVPN server: 10.x.0.1 (see also here for more details: https://airvpn.org/specs ). 10.4.0.1 is anyway accessible regardless of the port your system connects to. Kind regards

Hello! If you wish to tunnel DNS queries to Comodo, set Comodo DNS in your TAP adapter. Using non-VPN DNS ours prevents you to access VPN internal services (currently only speedtest.air) and also prevents you to access geo-discriminatory services from all servers (for example, if you wish to access BBC iPlayer from servers NOT located in the UK you must use our DNS). Kind regards

Hello! Try and monitor the packet flow in your interface (while disconnected from the VPN and everything should be blocked) with Packet Peeper or similar tools: http://packetpeeper.sourceforge.net If you see that packets flow out from your network card to various destinations, re-check your pf setup, make sure it is active, and if everything is confirmed please report to pf developers and/or Apple customer support. Kind regards

Hello! Actually it's interesting, those instructions suggest to restart the DHCP client service before trying a complete stack reset. In our tests, when the problem occurred, if an ipconfig /renew and a normal reboot did not work we jumped to reset the winsock catalog and perform a reboot, we did not try to restart the DHCP client service. If it works and it does not require the aforementioned reset, then the real cause of the problem would be detected, it would probably be a bug in the DHCP Windows service which is there since so many years. That would also explain why the problem has more chances to occur when default gateways are repeatedly DHCP-pushed. Kind regards

Hello! You don't have to reinstall, although re-installing and rebooting will for sure reset the TAP-Win32 Adapter, of course. When you have the problem, try the following steps (each successive step to be performed only if the previous did not solve the problem) - "ipconfig /renew" (from a command prompt with administrator privileges) - turn off and then turn on your physical interface - disable and re-enable the TAP-Win32 Adapter (this will cause it a reset), reset the TCP/IP stack and reboot, see http://support.microsoft.com/kb/299357 As far as we have seen, the last step always works, saving you the need, time and annoyance to uninstall and reinstall OpenVPN. It's an extremely rare condition, so it's not in the FAQ, sorry. It's also not easy to reproduce the issue, however a condition to enhance occurrence probabilities of such a behavior is repeatedly changing the default gateway. Kind regards

Hello! There's no such thing as an Air installation (the Air client is portable). If you noticed that after OpenVPN installation on the TAP-Win32 Adapter, it's probably just fine. 169.254.0.0/16 are the link local addresses in IPv4, they are only used to assign IP addresses to network interfaces when no external, stateful mechanism of address configuration (such as DHCP) exists (typically before the DHCP push from our OpenVPN server). The parameters with which Windows tries to determine if an Internet connection works or not are not reliable and can easily result in false messages. A typical example is when you block DNS queries outside the tunnel to prevent DNS leaks. When unable to resolve names, Windows will show you that you're disconnected from the Internet, while it is obviously false. Kind regards

@azarenko Hello! Apparently the screenshots you posted seem to confirm, not to deny, that pf is successfully dropping Skype packets. Kind regards

Hello! The tun interface did not come up. It might be a bug or a crash in the TAP-Win32 Adapter driver (unlikely) or a TCP/IP stack Windows handling problem. We have noticed that all Windows versions (tested on XP, Vista and 7) have issues when they are "stressed" with repeated changes of default gateway and routing table. Sometimes these problems require an "ipconfig /renew" to be solved, but (rarely) it's not sufficient, they require also a Windows socket (WinSock catalog) reset followed by a reboot (unfortunately a Winsock catalog reset seems to require a reboot to be completed...) or a reset of the physical network card. Kind regards

Hello! We have not had any failure or interruption of service on Cygni. The server performs very well and the latency times in a 10 countries continuous check are very good. https://airvpn.org/pingmatrix Swedish infrastructure is largely oversized at the moment, in relation to clients numbers and bandwidth requests. Any other feedback on Cygni from different premium users? Kind regards

@berniesnoek Hello! The problem is that the router tries to connect to a non-existing public IP address (10.x.x.x.). Please insert, in the "Server/IP" field of the OpenVPN configuration page of your router http interface, the entry-IP address of the Air server you wish your DD-WRT router connects to. An e-mail has been sent to you with further information. Kind regards

Hello! Yes, of course. If you connect to the same service with the same account with and without VPN, even without session cookies the service administrators can successfully perform a correlation. Another way to perform such correlation attacks against those who connect to the same service while connected and not connected to the VPN is via Flash cookies, which are not deletable by the browser. BetterPrivacy for Firefox takes care of Flash cookies ("supercookies") and allows their full deletion. Kind regards

Hello! Unfortunately it's unclear why you're trying to connect to a private IP inside the VPN (10.5.0.1). Can you please send us a screenshot of your OpenVPN configuration page in your DD-WRT router and the connection logs? Kind regards

Hello! Do you access the service status page while logged in? Do you allow javascript? You might like to look at the page source code for more hints. Kind regards

Hello! A guide to prevent any leak (including DNS leaks and leaks in case of unexpected VPN disconnection) for Windows with Comodo firewall: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 If you just want to prevent DNS leaks, you can either follow the guide in http://dnsleaktest.com or force the following DNS in your physical network card (ethernet and/or wireless): 10.4.0.1 as primary (preferred) DNS 10.5.0.1 as secondary (alternate) DNS In the above case please consider that your system will not be able to resolve names when disconnected from the VPN, therefore you'll need to edit your hosts file to add the resolution for airvpn.org in order to allow connection in case you use the Air client (future release of the Air client will adopt a different approach which will solve this issue and will be much more aggressive against censorship). See the above guide for more details about the hosts file. Kind regards

If you're behind a VPN, even if your DNS is leaking, your IP cannot be determined directly. If a site manages to find out your real IP, that's because it was likely done via cookies. Other mechanisms exist as well, via Javascript, Java and Flash. There may be other ways, as well. If you clear out your cache and cookies, then install a bunch of gatekeeper add-ons via Firefox, you should be alright. Maybe I'll write another guide on how to do this... Hello! Javascript by itself does not allow to read your network cards. If you accept to run .NET, Java and Flash code with administrator/root privileges, they can read your network cards. However, this operation by itself in general is not sufficient to disclose your real IP address with OpenVPN in routing mode, because none of your network cards know the real IP address assigned to you by your ISP: the tun adapter has the internal VPN address, while the IP address of the physical network adapters is the one assigned to the computer by the router (if the system is behind a router NAT, a very common situation). You can imagine malware which tries to read the router configuration, but then again you must provide the malware with root privileges AND give it the password to access the router configuration, unless the router is totally unprotected, or unless the router publishes on the home page of its web interface the assigned ISP IP address, in which case the malware can detect the router IP address by reading your network cards and then access the router http interface and parse it to extract the real IP address. If your router publishes on its home page the IP address assigned by your ISP, a trivial but effective protection against such malware is dropping packets toward your router IP address port 80. For example, in Comodo, defining a top global rule (before the Allow rules in our guide) like the following: Block TCP Out From IP In [Home Network] To IP Where Source Port Is Any And Destination Port Is 80 (remember to delete this rule when you need to access your router configuration page via http). Important: if any of your network cards contains the IP address assigned to you by your ISP (for example if your computer is directly connected to the ISP network without any NAT router) then letting root privileges to any unknown application is an unacceptable risk. But also in general no application that you don't know very well should be authorized to run with elevated privileges and it is mandatory, as a general rule, not to leave the configuration router settings accessible without a password. Kind regards

Hello! The alleged "NL menace" is currently a fantasy, the cited legal framework is a mix od draft proposals which can't in any way infringe the EU legal framework on privacy and data protection, the ECHR and the Charter of Fundamental Rights of the European Union. That said, if you assume that your adversary has the power to wiretap in real time (even illegally) all the VPN servers, capture the traffic, correlate the incoming and outgoing traffic, you can defeat such an adversary with partition of trust. You might like to read the following article: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=54&limit=6&limitstart=6&Itemid=142#1745 Kind regards