Staff

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Germany is available: Tauri. The AirVPN client will show automatically this new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificate/key generator (menu "Member Area"->"Access without our client"). The server accepts connections on port 53, 80 and 443 UDP and TCP. As usual, no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN admins

Hello! Both the Air client and Viscosity are OpenVPN wrappers and GUIs, therefore there's no difference in security or speed. Please note that the Air client is available for Windows only, and that it retrieves automatically certificates, key and configuration for OpenVPN through an SSL connection, while Viscosity needs those files in your system (you can download them anytime from menu "Member Area"->"Access without our client"). Kind regards

Hello! You are right and we will solve the issue with a new server in Germany in a few days. You will be kept updated on the forum. [EDIT] A new 1 Gbit/s server in Frankfurt has been added. Kind regards

Hello! Can you please make sure that you flashed a firmware with "OpenVPN flavor"? Kind regards

Hello! Please make sure that openvpn.exe is in the trusted applications list as well. Kind regards

Hello! Thanks. Command "nslookup" may also help you. See the various responses of nslookup when DNS resolution works and when it does not. Just in case it's useful for your troubleshooting, keep in mind that Windows has the notion of a DNS setting per each adapter, it does not see a global DNS like Linux. Kind regards

Hello! We have received complaints about our server Lyra trying to exploit a Windows old critical vulnerability MS08-067 http://technet.microsoft.com/en-us/security/bulletin/ms08-067 This means either that some malicious client is launching attacks from Lyra or, more probably, that one or more computers' clients connected to Lyra are infected with a worm: http://blog.threatexpert.com/2008/10/gimmiva-exploits-zero-day-vulnerability.html We remind you that our ToS forbids to spread malware through our servers as well as launching attacks against any system. We don't think that such attacks are deliberate: no serious attacker would try to exploit a critical vulnerability fixed 4 years ago. We strongly recommend our customers who use Windows and were connected to Lyra in the last 2 days to check for virus, worms and malware on their systems and keep their Windows OS up to date. The aforementioned worm and trojan family is very dangerous, it can act as a keylogger on the infected system and will try to steal sensitive information, therefore destroying (for the user who use the compromised computer, not for the victim of the attack who hopefully has updated his/her system since 2008) the anonymity layer we provide: http://www.threatexpert.com/report.aspx?md5=06fbcf231d6db6e97d4dba5251252658 Kind regards

Hello! Does it happen for you both with Vega and Sirius? Kind regards

Hello! Yes, that's precisely what you get by default. Our servers push a routing table that accomplishes what you want. The routing table is the same regardless of the port you pick to enter the VPN. Kind regards

Hello! Please see the Frequently Asked Questions on this specific question https://airvpn.org/faq Ok, that's what happens by default. Our servers will push the appropriate routing table. It's strange that you lose DNS resolution ability after a while. When it happens, check whether your system can reach the DNS IP address. Please see here if you use our DNS: https://airvpn.org/specs That's correct. The TUN/TAP interface is used by OpenVPN. If you give a "route print" command while connected to an Air server you can see your routing table and the "path" of your packets, while "ipconfig /all" will show all the details about all your network cards (real and virtual). If you wish to monitor all the packets traffic in your system, the "active connections" in Comodo firewall will give you a general overview, while you can use tools like Wireshark for a full-details packets monitoring. http://www.wireshark.org/ Please do not hesitate to contact us for any further information or support. Kind regards

Hello! Please note that Aurigae will not accept connections and that already connected clients will be disconnected at 23:30 CET+1 on May, 22 2012. Taking down Aurigae is momentarily necessary in order to allow us to fight in the best way copyright trolls which are massively bombing with alleged copyright infringement notices the exit-IP address of Aurigae, making one of our providers upset. There's no reason to worry since we are prepared for such incidents. Our infrastructure is sufficiently redundant to provide plenty of bandwidth in the USA with the other US servers. We will keep you informed. Kind regards

Hello! Thank you very much for your accurate testing. As you can see, your results seem to show that the packet loss happen outside "our" network. Such minimal packet loss toward portlane is probably normal with UDP, anyway it is not possible to rule out that some piece of infrastructure between portlane (or in portlane) and the various datacenters where our servers are located, or between you and "our" datacenters, does not work optimally. It seems unlikely that the datacenters where we have servers have ALL the same problem. Kind regards

Hello! No worries, just a Kunena glitch. It looks like outbound port 443 UDP is blocked on your system. Can you please check that some firewall is not blocking OpenVPN? Also, in case your ISP has started blocking 443 UDP or other UDP ports, try a TCP connection (for example to 80 TCP). We're looking forward to hearing from you. Kind regards

Hello! Excellent, checkmytorrentip is a reliable test. You might also like to read this: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&Itemid=142 Kind regards

Hello! The most common cause of this problem is a firewall blocking OpenVPN. Can you please check? Also, please try a connection to a TCP port, just in case some UDP ports are blocked/capped by your ISP, on different servers. We're looking forward to hearing from you. Kind regards

Hello! The TAP-Win32 interface does not come up. Please make sure that it is installed and it has not been deactivated. Furthermore, make sure that the Air client is launched with administrator privileges and that the Windows DHCP (client) service is active. Please perform some tests with Windows firewall disabled (if you use the Windows firewall). See also here: http://forums.openvpn.net/topic8441.html and more importantly here: http://forums.openvpn.net/topic8811.html If you can't manage to bring up the TAP-Win32 adapter: - completely uninstall OpenVPN; - re-install OpenVPN 2.2.2 and make sure that you authorize it to install any driver it will ask you for Kind regards

Hello! Yes, thanks! Ok, have a look here to add rules in order to secure your VPN connection with iptables: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&limit=6&limitstart=30&Itemid=142#2010 Kind regards

Hello! Very good to know, thank you very much indeed. Kind regards

Hello! Can you please send us the complete iptables tables/chains? The rules you mention do not appear to prevent leaks from your br0 in case of VPN disconnection. Kind regards

Hello! Yes, you're fine, just do not forward ports on your router. If you forward both remotely and on your router the same ports, an adversary with the ability to monitor/wiretap your line can send packets to the same port both on the exit-IP of the VPN server you're connected to and to your real IP address. If the service you're running responds also the the packets arriving to your real IP address outside the tunnel, the adversary have established a correlation between you and the VPN usage on that port. Kind regards

Hello! Can you please send us the connection logs? Right-click on the Air dock icon, select "Logs" and click on "Copy to clipboard", then paste here. Kind regards

Hello! Thank you for all the tests, they are very interesting. If you have time, check with a TCP connection if you still have packet loss, both on Castor and Draconis. 0.1% and 1% packet loss on UDP OpenVPN tunneling may be acceptable: OpenVPN may resend packets even in UDP, so you will suffer really a minimal performance loss (probably you won't even notice the difference with respect to a 0% packet loss). Unfortunately, at the moment we have no plausible explanation about why you detect packet loss on 443 UDP but not on 80 UDP with Castor. And yes, we detect rarely packet loss when there's high latency from OpenVPN clients in Italy to any VPN server on UDP ports, between 0.05% and 0.1%. It is not our servers fault (exception: a couple of months ago we had a dramatic packet loss on Delphini, but that was just because a network card was broken), however we'll perform further tests with Draconis. Thank you for the correction about Uppsala. Kind regards

Hello! a. Yes, it is possible. We can add additional ports if they are useful to bypass censorship, for example. b. OpenVPN has the ability to establish connections over a proxy. If you wish to do so, select the appropriate proxy type. If you don't need to use a proxy, leave the field to "None". Typical examples for connections over AirVPN over a proxy are AirVPN over TOR (https://airvpn.org/tor) or when the client is behind a corporate proxy. c. FAQs are available here: https://airvpn.org/faq AirVPN is based on OpenVPN: http://openvpn.net/index.php/open-source.html Feel free to use the forum, the helpdesk and the "Contact us" form for any further information or inquiry. Kind regards

Hello! The website was unavailable at 10 PM (CET+1) for about 40 minutes, the problem has been fixed. Please note that in case of website unavailability, you can anyway connect to any VPN server via OpenVPN. Kind regards

Hello! The "Replay-window backtrack occurred" showed in the logs is a hint that you have (not necessarily always) high latency with our servers. While this may or may not disrupt the connection, using a TCP port will surely mitigate the problem, especially during the handshake, and actually you could fix the issue with a TCP connection. TCP provides full error-correction, while UDP does not. Please see the FAQ for more information. Kind regards