Staff

Hello! Don't worry, it's not your or your browser problem. Currently the forum messages need to be approved by a moderator to show up. We took this decision to fight spam. Kind regards

Hello! Please change "Direction" in the rule to "Out" only. "In/Out" will block any incoming packet for the application not coming from 10.4.0.0->10.9.255.255, effectively blocking any chance for the application to receive any packet. Kind regards

Hello! We're glad to inform you that a new servers monitor has been implemented. The new monitor provides a completely redesigned graphics, additional efficiency and plenty of new information. The new layout will let you be informed more quickly and pleasantly about the status of the Air infrastructure. The monitor will also allow us to inform you with more effectiveness about the status of the VPN servers. Each server can have a short message informing you of potential problems or any other relevant information. New aggregated data have also been added on the right column. In the "Geographical distribution" table you can see the total of connected clients, used and available bandwidth divided into planets, continents and countries. The "Top 10" tables on the right column show the highest detected data in the specified field pertaining only to currently online clients. Nick names are not displayed, however from your "Settings" menu you can allow the display if you wish so. The tables are useful to check stability and verify the performance of the network. The monitor is accessible at the usual link https://airvpn.org/status As usual your feedback will be appreciated. Kind regards

Hello! Your list is just fine, there's only that "alien" 176.61.136.35. Kind regards

Hello! We noticed that, but it's a geo IP location error. The server is in a datacenter in Los Angeles. Kind regards

Hello! Sorry, we're not familiar with your firewall. Anyway, since it's a commercial product, surely their customer support will be able to translate the Comodo rules for you in 1 minute. You should change that rule allowing connections to destination IP 255.255.255.255. To understand why your rule will not necessarily work all the times in the DHCP "negotiation": http://support.microsoft.com/kb/169289 Apparently this is the wrong approach. Allowing indiscriminate communications to port 443 will not prevent all the leaks, for example from your browser to https websites, if your browser is not in the blocked application list. About the block rule, you will have to insert any and each application that you want to secure against leaks, however remember NOT to insert openvpn.exe and airvpn.exe amongst those. Furthermore, it is unclear how you can prevent DNS leaks with this approach. If you put svchost.exe in the secured application list rule, you won't have connectivity at all at the boot or when disconnected from the VPN (not even a successful DHCP handshake), so you would be forced to switch on and off continuously the rule for svchost.exe in order to prevent DNS leaks. All in all, probably you can speed up your work and obtain better results just translating Comodo global rules into LooknStop rules. Kind regards

Hello! It's a nice idea and we have evaluated it. However we consider OpenVPN over TOR much more secure. A multihop VPN with all servers belonging to the same entity might add just a very thin additional security layer. Of course we could create separate entities/companies which handle various servers, however it's difficult to see a real advantage in comparison to Air over TOR. Kind regards

Ahhhhhhhh this is perfect, I did not know this. I thought it would be for the entire router. That makes this whole thing a lot easier. Hello! Yes, DD-WRT supports Policy Based Routing with multiple routing tables. If you're curious, start from here to get an idea: http://www.dd-wrt.com/wiki/index.php/Policy_Based_Routing and then have a look here: http://www.dd-wrt.com/wiki/index.php/OpenVPN So you might say, for example, that 192.168.1.101 uses the tunnel, while 192.168.1.102 does not. Kind regards

Hello! During the login phase, airvpn.exe establishes an SSL/TLS connection with airvpn.org. It seems that your system does not trust the airvpn.org certificate. Kind regards

Hello! Yes, probably it's a different problem, please send us the logs in case you won't solve it. Our servers will push routes to tunnel ALL the traffic. You will have to modify the routing table or reject our servers push (with nopull directive) and then build carefully your own routing table in order to "split" traffic. DD-WRT also lets you select which devices on your WAN will use the tunnel and which not. Kind regards

Hello! Please right-click on the Air dock icon, select "Logs", click on "Copy to clipboard" and finally paste. We're looking forward to hearing from you. Kind regards

Hello! We need additional information to support you properly. Can you please tell us your device, OS and client (for example Air client, OpenVPN direct, OpenVPN GUI, Tunnelblick...) you're using to connect? Also, can you please send us the logs of the client? Kind regards

Hello! Fine, just check that your device IP is defined as 192.168.0.0/24 in ipfw rules (192.168.0.0/16 would anyway work, it's just bigger). Just connect to the port which gives you best performance. If your ISP does not perform any port shaping, ports 53 and 443 will give you the same performance. You might also like to check the Vega, Bootis and Leporis entry IP addresses: Bootis 31.193.12.74 Leporis 95.211.191.33 Vega 69.163.36.66 EDIT: this is jessez's script with clear and explanatory comments: https://airvpn.org/media/kunena/attachments/33554/AirVPN-CommandlineDocumentation.txt Kind regards

Hello! Sorry, it was assumed that you used pf, not Waterrof+ipfw. Those instructions are for pf. You can follow this: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&limit=6&limitstart=42&Itemid=142#2756 (see also the subsequent messages). Kind regards

Hello! You might follow this good tutorial: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&limit=6&limitstart=36&Itemid=142#2532 If you get stuck at any step, please do not hesitate to contact us. Please provide us with as many information as possible about your problem (if any). Kind regards

Hello! That's correct, account "sys_op" is already connected to one of the Air servers. It was connected since about 30 minutes before your post. At the time of writing "sys_op" is still connected and exchanging data. Please note that multiple connections with the same account are not possible. Kind regards

Hello! We've warned the provider about the issue. We will keep you informed. Kind regards

Hello! The Comodo rule is just fine, therefore it is likely that the red token for your UDP port is just a false positive (it may happen with UDP). Please drop us a note while you are connected, so that we can check in real time the "Not reachable..." message and port forwarding for your account. Also make sure that the port(s) eMule listens to do match the ports you have remotely forwarded on our system. Kind regards

Hello! Sorry, the remote-random directive was already included. Please note that the servers you comment as in "Switzerland" are actually in the USA and server 176.61.136.35 is not an Air server. Kind regards

Hello! Sorry, this was another problem, apparently AEC forced some hours ago the expiration of your account for unknown reasons (probably human error, we'll investigate). We have now re-activated "nigelmansell" and set the proper expiration date according to your various subscription plans. Please do not hesitate to contact us for any further information or issue. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in the USA (Los Angeles, California) is available: Pegasi. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/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! In order to prevent Hamachi nodes to see your real IP address you need to tunnel over Hamachi over OpenVPN (not OpenVPN over Hamachi). With two computers or a computer with two physical network cards you should be able to accomplish the task. Computer A acts as an Air client and a gateway for computer B. Computer B connects to computer A and launches the Hamachi client. In this way our servers will see encrypted by Hamachi traffic, while Hamachi nodes will see the exit-IP address of one of our servers. EDIT: according to one of our users, computer B may also be a Virtual Machine guest hosted in computer A (thank you bartek). Just in case you have a DD-WRT or Tomato router, you can do just the same: connect the router to an Air server, then run Hamachi client on one computer which is connected to the router. This is pure theory, none of us has tried the setup. Unfortunately Hamachi is proprietary and not well documented software, so some trial-and-error process might be necessary. Kind regards

Hello! As far as this admin knows it's not possible, because Hamachi client installs and uses a virtual network adapter (similarly to what OpenVPN does with the TUN/TAP adapter). So you just can't tell OpenVPN to connect over Hamachi, as you would normally do with a socks or http proxy, or if you wished to tunnel over OpenVPN over SSL and SSH. The most obvious solution that comes to mind would consist of a separate server which acts as an Hamachi client and an OpenVPN or ssh server, and then your device connects to that server via ssh or via OpenVPN. Hamachi would therefore see the IP address of the separate server. However, the knowledge of this admin about Hamachi is limited, so your question will be passed over to another admin for further evaluation in the next days. Kind regards

Hello! We are making extensive research for a reliable datacenter in Asia. Unfortunately none of those we have found meet our privacy and net neutrality requirements and/or they don't meet our bandwidth/traffic requirements. Exactly, those servers have a soft limit of 100 Mbit/s, but the provider allows temporary bursts. Anyway we don't recommend to connect to servers near 100% capacity. This is a dilemma for us: until now we have always left total freedom to our customers to connect to the server they wish. However, if they don't pay attention to the server loads, they might believe that the service is slow. On the other hand, capping the number of users on each server according to capacity is somehow an intrusive enforcement which does not respect customers' will. Momentarily, we'll keep pursuing our policy of constant infrastructure expansion according to needs, pushing even more on bandwidth redundancy. This might not be the optimal solution under a marketing short term point of view, but it may well be the best solution on the long run. Kind regards

Hello! We are sorry, currently SSTP support is not planned. Is there any particular reason for which you would prefer it instead of OpenVPN on port 443 TCP? Please consider that if you can use UDP, OpenVPN is much faster than SSTP, it solves all the problems of IP over TCP, while keeping a higher authentication security. Kind regards