Staff

Hello! We have had a major problem on one of our backend servers which prevented new connections. The problem has now been fixed, can you please try again? We're still working on the system, so if you find any issue please do not hesitate to contact us. Kind regards

Hello! We have had a major problem in one of our backend servers. It did not affect already established client connections but it did prevent new connections for 5 hours. The problem has been now fixed. However, we're still working on the system, so please do not hesitate to contact us for any issue. We apologize for the inconvenience. Kind regards

Hello! We have had a major problem in one of our backend servers. The failover system worked only partially and we needed some time to restore everything. The problem did not affect already connected clients, but it did prevent new connections for about 5 hours. The problem has been now fixed. We're still working on the system, therefore please do not hesitate to contact us for any issue. We apologize for the inconvenience. Kind regards

Hello! We're sorry, we use OpenVPN in "routing mode". The adapter, both on the server and client side, must be a TUN interface operating on layer 3, not a tap adapter handling layer 2 packets. If you use OpenVPN in bridged mode, you can't connect to Air servers. That said, it remains to be seen whether what you want achieve is possible with PPTP. Your household machine should act simultaneously as a PPTP server and OpenVPN client. Unfortunately we are not able to give you support on this and we can't say for sure if it's possible or not. However, it is definitely possible (at least on Linux) to run multiple OpenVPN instances, each running either in server or client mode, with an arbitrary number of tun interfaces, and it is also definitely possible to use a Linux box as a simultaneous OpenVPN server for its clients and an OpenVPN client for the Air servers. It is possible to do that even with just one physical network card. You will need to modify the routes pushed by our servers to your OpenVPN client, enable IP forwarding and set an appropriate routing table which allows packets routing and NATting between OpenVPN server and client. The setup requires a fairly good knowledge in networking, anyway you can be sure 100% it's possible (with only one physical network card) because we do that for services both for our clients and for internal purposes. Kind regards

I changed my firmware version and was able to connect! The OpenVPN setup page on DD-WRT wouldn't accept LZO Compression set to "yes" only "adaptive". Hello! That's great, thank you for the information. Could you please specify the exact firmware version that is working with your router model? That does not necessarily mean that you have a DNS leak from your router. First please check that you really have a DNS leak here: http://dnsleaktest.com Then, please make sure that the leak is not caused by the devices connected to the router (do not force them to use different DNS servers). If the leak is confirmed, you might like to read the zdrifter post about that and more (it will prevent any leak): https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=2377&Itemid=142#2377 Kind regards

Hello! The peering of our servers datacenters did not change in the last 2 weeks and the recorded performance is as high as usual. Furthermore we also added more bw redundancy. Please note that: - our NL and DE servers are in datacenters with POPs directly connected to tier1 providers with high bandwidth redundancy - you find the very same problem on different datacenters and networks - 2 weeks ago you recorded "blazing speeds" - you record high performance during the first minutes, then you lose connection or you have very high packet loss Therefore and unfortunately everything, really everything, suggests that it is a problem either of your ISP (or the ISP of your ISP etc.) or maybe of your last-mile, born during the last 2 weeks, Unfortunately, in this case, there's nothing we can do. If it was a fault on our side, we could work on it, but given the information you provided the problem is on your side and we are powerless. Just to try all the options, maybe it is not your ISP fault, but only a faulty router which shows the defect especially during tunneling (you would hardly notice dropouts without tunneling). Kind regards

The log showed that I do connect but then disconnect. I tried the connection with the same configuration again with the same results. The STATE keeps showing Client:RECONNECTING. 20120912 21:06:22 I TCP connection established with 108.59.8.147:80 20120912 21:06:22 I TCPv4_CLIENT link local: [undef] 20120912 21:06:22 I TCPv4_CLIENT link remote: 108.59.8.147:80 20120912 21:06:22 TLS: Initial packet from 108.59.8.147:80 sid=686390b6 ba017dab 20120912 21:06:23 VERIFY OK: depth=1 /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org_CA/emailAddress=info@airvpn.org 20120912 21:06:23 VERIFY OK: nsCertType=SERVER 20120912 21:06:23 VERIFY OK: depth=0 /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=server/emailAddress=info@airvpn.org 20120912 21:06:23 MANAGEMENT: Client connected from 127.0.0.1:5001 20120912 21:06:23 D MANAGEMENT: CMD 'state' 20120912 21:06:23 MANAGEMENT: Client disconnected 20120912 21:06:23 MANAGEMENT: Client connected from 127.0.0.1:5001 20120912 21:06:23 D MANAGEMENT: CMD 'state' 20120912 21:06:23 MANAGEMENT: Client disconnected 20120912 21:06:23 MANAGEMENT: Client connected from 127.0.0.1:5001 20120912 21:06:23 D MANAGEMENT: CMD 'state' 20120912 21:06:23 MANAGEMENT: Client disconnected 20120912 21:06:24 MANAGEMENT: Client connected from 127.0.0.1:5001 20120912 21:06:24 D MANAGEMENT: CMD 'log 500' 19700101 00:00:00 Hello! It might be a firmware problem. Can you please try to change version? Kind regards

Hello! Yes, a new servers real time monitor which will provide you with more information is almost ready. Kind regards

Hello! This is normal: Comodo can't know the exact range of our network zones. You can avoid this annoyance defining a network zone which covers the range 10.4.0.0->10.9.255.255. For more information please see https://airvpn.org/specs We have noticed those problems intermittently and we have partially solved them, we're still investigating. Currently you should not have any problem, neither on the website nor with servers connection. Please do not hesitate to contact us for any further issue. Kind regards

Hello! uTorrent is capable to perform the correct UDP Hole Punching through our VPN servers NAT. Skype is considered to be able to do that too. This is possible because Air implemented NAT is p2p friendly, a "cone NAT" (see RFC 3489) . It "focuses" all sessions originating from a single private endpoint through the same public endpoint on the NAT. (Ford, MIT, "Peer-to-Peer Communication Across Network Address Translators", 2005). (Ford) For (a lot of) additional information please see http://www.brynosaurus.com/pub/net/p2pnat , in particular paragraphs 3.2, 3.4 and 5.1. Kind regards

Hello! Thank you very much, your words are much appreciated. We are committed to providing you with an ever improving service. Kind regards

Hello! Please check whether all the files inside the zipped archive have been copied and pasted into the proper directory (for example /sdcard/openvpn). Besides the .ovpn configuration file(s), you must see ca.crt, user.crt and user.key. Absence of any of those files will prevent your device to connect. In particular, absence of user.key will cause the client to prompt you for (an impossible) authentication Kind regards

Hello! Can you please make sure that your ISP router is working in bridge mode? About the "Unroutable control packet received" error, it is normally due to an invalid certificate (expired or not yet valid). Please check your routers system clocks and that you have properly pasted ca.crt and user.crt. Kind regards

Hello! The logs show that the connection was fully successful. Could you access the Internet from your DD-WRT connected devices ? Kind regards

Hello! When Serpentis is under flood / DDoS attacks, the hardware firewall in front of it drops UDP packets [EDIT: correction, it shapes UDP traffic against flooding] in order to let Serpentis continue providing the service on TCP ports. Kind regards

Hello! We don't detect any problem on any Serpentis port. All the monitoring & supervision systems show that Serpentis is up and running, listening to and accepting connections on all the designed ports. Is anybody else facing the same problem? Kind regards

Hello! In general no, you should not (anyway you can change your mind whenever you wish) because in that case DNS queries and answers will be tunneled through servers, instead of resolving names directly with our DNS, with a slight performance decrease. Please note that if you wish to use Comodo DNS, you will have to force them on your TAP-Win32 adapter, because our OpenVPN servers will always push the internal DNS server IP address https://airvpn.org/specs Kind regards

Hello! SSL (as well as OpenSSL) fully supports AES. Your browser will pick one of the supported encryption and key exchange systems available on your computer. By default, browsers like Firefox have RC4-40 bit disabled. Examine the airvpn.org certificate and encryption from your browser for more details. In Firefox you can enable and disable ciphersuites through the advanced settings accessible in about:config page (look at the security.* entries). You can force your browser to employ AES 256 with https, which is fully supported on our web frontend, if you prefer to connect in this way with our website. Your guess is right but maybe for the wrong reasons. However, connecting to our site when already connected to the VPN gives different advantages (bypass IP blocking, DNS poisoning, avoid mitm attacks and site forgery and prevent your ISP to see that you connect to this website). Kind regards

Hello! Yes, your assumption is correct. Inside the zipped archive you will find not only the certificates but also your private key. No prompt for username and password should be issued by your client. From the logs, apparently your client is correctly accessing both certificates (ca.crt and user.crt), but not the key (user.key), can you please check? Kind regards

Hello! Can you please try a connection to a TCP port in order to determine whether the problem lies in outbound 443 UDP? Kind regards

Hello! Can you please make sure that your ISP router is working in bridge mode? Also, can you please try connections to a TCP port in different servers, to check whether you have problems with outbund port 443 UDP? Kind regards

Hello! Can you please clarify? OpenVPN connections in Air use AES-256-CBC packets encryption. You might like to read here: http://en.wikipedia.org/wiki/Transport_Layer_Security Kind regards

Hello! We're sorry, even if Viscosity supported that, while an account can switch servers without limits, it can connect only to one server at a time. If you wish to achieve a "multi-hop" encrypted chaining, please consider https://airvpn.org/tor Kind regards

@gpiper Hello! The attached screenshot show a correct configuration. Can you please check iptables rules and make sure that certificates and key have been properly copied and pasted? Can you also send us the OpenVPN logs? Please not that the image links have been removed because of spam and incorrect behavior of the image hosting service used, anyway they have been correctly displayed before the deletion. You can freely attach images directly on out forum. Kind regards

Hello! Most probably you are not talking with your ISP DNS server. Comodo correctly drops those unsolicited ICMP packets. Why your ISP DNS sends you ICMP packets remains to be seen, but a good hint is given on the last message of this thread: http://forums.comodo.com/empty-t16873.0.html Anyway, you can additionally (if you haven't already done so) configure Comodo to prevent any leak (including DNS leaks, which are Windows "endemic") for total security: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 Kind regards