Staff

Hello! Not really, when disconnected from the VPN your computer will just be unable to resolve names with DNS queries: this will not prevent all the potential leaks in case of unexpected VPN disconnection. If you wish to block your Internet connectivity when disconnected from the VPN to prevent ANY leak, please follow this guide: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 Kind regards

Hello! You have to add those two lines at the bottom of the file. Open it with Notepad (launched with administrator privileges), add the two lines at the bottom, do not modify anything else, save the file and close Notepad. Kind regards

Hello! Sorry for the clarification request, do you mean that OpenVPN GUI crashes as well? Kind regards

Hello! The Global Rules and Network Zones look just fine. As a side note, you might like to add to your [airvpn.org] Network Zone the IP 212.117.180.25 (another frontend), so that if the NL frontend fails, your system will be able to use the other one. Remember to add the appropriate lines in your hosts file as well: 85.17.207.151 airvpn.org 212.117.180.25 airvpn.org The problem should be somewhere else in Comodo (maybe in the Application Rules, maybe in the Defense+ authorizations). Please re-check your Application Rules to see whether some system application has been blocked. Also, try to see Comodo event logs when you try a VPN connection (feel free to send them to us as well) to check whether Comodo firewall is blocking something it should not. Kind regards

Hello! Probably Comodo Firewall and/or Defense+ (HIPS) and/or Sandbox modules are preventing airvpn.exe and/or openvpn.exe to run with full administrator privileges. Please make sure that both programs are "Trusted Applications" and that they are not forced to run in a sandbox (a very useful feature of Comodo, but in this case both programs needs administrator privileges to run properly, they can't run in a sandbox). If the problem persists although both executables are trusted and not sandboxed, please send us a screenshot of your Global Rules and a screenshot of your Network Zones. [EDIT] Maybe you have already solved the problem? At the moment of this writing, your account is successfully connected to some Air server and is successfully exchanging data in/out. Kind regards

Hello! Your experience with the Norton customer support sounds terrible. Anyway, can you please make sure that the "Type of rule" that you set in the Norton "Rules Wizard" was set indeed to "Block" value? Did you receive the e-mail from the support team? Pasting it here just in case it is useful to some other user: Your physical network interface is From ipconfig /all, your subnet IP range is either 10.0.0.0->10.0.255.255, 10.0.0.0->10.0.1.255, or 10.0.1.0-->10.0.1.255. Let's assume it's the first, which covers the second and the third as well (if it's the second or the third, using the first will do no harm). We don't know the formats in which Norton firewall accepts IP ranges. If it accepts IP/NetMask CIDR notation, you can use 10.0.0.0/255.255.0.0 If it accepts IP/BitMask slash notation, you can use 10.0.0.0/16 If it accepts IP ranges, you can use: Start: 10.0.0.0 End: 10.0.255.255 [PLEASE NOTE THAT IN THE ORIGINAL E-MAIL THERE WAS A MISTAKE ON THIS ADDRESS] All of the above notations are equivalent, so just use the one which Norton wants. Kind regards

Hello! The tun/tap adapter DNS is DHCP-pushed by our servers. Your current setup does not seem appropriate to prevent DNS leaks, keep an eye on them. Kind regards

Hello! No. Only if you put the VPN DNS IP addresses your DNS queries will be tunelled in any case. Yes, of course: it must NOT work, that's the purpose. Also, that's why you need to modify your hosts file in order to allow (re)connections to Air VPN servers through the Air client. No. The leaked queries will go to OpenDNS unencrypted, out of the tunnel, and your ISP can see them. Kind regards

Hello! Normally you just need to connect your server to an Air VPN server with OpenVPN. OpenVPN will take care of routing table and default gateway and all applications will be tunneled transparently. Just connect (you might like to do that from inside a "screen", to avoid that when you disconnect from ssh the sessios is lost and OpenVPN stopped) launching OpenVPN with the configuration file you prefer (see also https://airvpn.org/linux ). Kind regards

Hello! The path to the hosts file (in standard installation) is: C:\Windows\system32\drivers\etc The file name is "hosts", no extensions. Edit it with any text editor (for example NotePad) launched with administrator privileges. Add the lines at the bottom of the file. Kind regards

Hello! You can either pick pf or ipfw. However ipfw is deprecated by Apple and pf is a more modern and powerful packet filtering tool, so you might probably prefer to go with pf. In the guide, thanks to the courtesy of jessez, you can find example scripts which are almost ready-to-use and require only minor modifications. Yes, it's compatible. It must not interfere with OpenVPN and with your OpenVPN wrapper (Tunnelblick, Viscosity...). Kind regards

Hello! Can you please try OpenVPN GUI? Kind regards

Hello! The quoted line is clearly a bug in the configuration generator. It has been fixed, please re-generate the file. We apologize for the inconvenience. Kind regards

Hello! The path to the hosts file (in standard installation) is: C:\Windows\system32\drivers\etc The file name is "hosts", no extensions. Edit it with any text editor (for example NotePad) launched with administrator privileges. Add the lines at the bottom of the file. Yes:, if you force 10.4.0.1 as primary and 10.5.0.1 as secondary DNS on your physical adapter, when svchost.exe sends a DNS query to the DNS IP address set for the physical adapter, that query will follow the routing table, so no DNS leaks at all. Kind regards

Hello! Can you please make sure that you're not running the correct Air client version? Check here: https://airvpn.org/windows In order to connect over OpenVPN over OpenVPN, the quickest solution is running a host and a virtual machine. The VM must be connected to the host via NAT (VMWare and VirtualBox have a quite complete NAT support). The host connects to the first VPN (VPN 1), the VM to the second VPN (VPN 2). All the applications in the VM will connect over VPN 2 over VPN 1. This setup assumes that both VPN are based on OpenVPN. Kind regards

Hello! Location of the hosts file may vary on different Windows versions, what is yours? Kind regards

Hello! Can you check line 10 of your original configuration file (the one generated by the configuration generator)? Can you paste that line here (or the whole file, as you prefer)? It seems not a permission problem, it might be either a previously undected bug in our configuration generator (when you select "Earth") or a bad parsing by Tunnelblick when it imports that configuration. EDIT: we confirm it was a bug in the configuration generator when it was used "Earth". It has been fixed, please re-generate the file. We apologize for the inconvenience. Kind regards

Hello! The logs point to a permission problem, can you please look at the Console Log just after the problem occurs for more details? Kind regards

Hello! You're right, in various areas DNS leaks must be taken seriously. The DNS queries sent by your router are almost surely unencrypted. Check here: http://ipleak.net while your computer is connected to the VPN. It is necessary to determine why your system is sending queries to the router (which in turn sends them to OpenDNS). What is your OS, is it Windows? Kind regards

Hello! Ah good, thank you, the previous admin did not see that. Kind regards

Hello! This is the main problem: https://groups.google.com/forum/?fromgroups=#!topic/tunnelblick-discuss/_1Q1a2qZ9d4 Kind regards

Hello! First of all, thank you very much for your report about Shimo. What you say about Mac is true, there's no GUI for Mac that is capable to use every OpenVPN feature. On the other hand OpenVPN over TOR or over any proxy is an additional service not strictly depending on us. It would be absurd that additional features independent of our system should bind us to any commitment, especially when those features are perfectly accessible with a single command. Moreover, all the Air system is designed so that the user is not bound to use an Air proprietary client, which is vital under a security and openness point of view. Yes, definitely, and we'll try to explain why here, without any polemic intent, but to make you understand the reasons of our choices. Your opinion could be easily interpreted like we should not be offering any advice on how to use OpenVPN fully because some system does not have a GUI to use every OpenVPN feature. What's more, as you have surely noted, we have added some significant features (without any increase in price) which are vital to use a VPN in several countries (simply because VPN connections are actively disrupted). Should we stop offering native OpenVPN over SSL and over SSH support directly on our servers because there's no GUI on any OS to use them? Should we had stopped offering remote-random directive because Android and iOS official OpenVPN clients did not support it (until a couple of weeks ago)? Should we had provided insecure PPTP-based tunneling when Air was born, because OpenVPN was not available in iOS and because Apple was actively forbidding its customers to run OpenVPN on iPhone/iPad/iPod? Should we stop offering explicit-exit-notify and embedded configuration files because network-manager for Linux does not respect that directive and does not support embedded configuration files? And the list can go on. As you said in your previous post, we also "aim to support open platforms and free speech on a self-sustaining environment". The lack of a GUI that is able to take full advantage of every OpenVPN feature will not stop us from providing any useful additional service OpenVPN is capable of and we will never force our customers to use any proprietary software from us. Kind regards

I know, that is why I wrote that things were working perfect on your side. But you do not provide a native client for Mac platform and I do not know a way of using your service without using the mentioned wrappers which do not support SOCKS proxies. Hello! You need to launch OpenVPN directly from a shell. Put your configuration files (i.e. the files generated by our configuration generator) on any directory you like, enter the directory (with the command "cd ") and issue the command: sudo openvpn Remember to launch TOR before (or your socks proxy), if the generated configuration file is built to order OpenVPN to connect over a socks proxy. sudo is necessary because OpenVPN needs root privileges to modify the routing table and the default gateway. Could you please explain this in more detail? Do you really think that it is appropriate for the intermediate users? It depends on the definition of intermediate user. In order to launch OpenVPN, the user must be able to install it, create a folder, copy & paste files (these last two operations are anyway required even if the user uses Tunnelblick), open a command shell and type in the above mentioned commands. Probably most Mac users are able to do that. Kind regards

Hello! You might also like to read here to connect over OpenVPN over TOR on a Mac: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=8860&Itemid=142#8864 Kind regards

Hello! Thank you for your nice words, they are much appreciated. Tunnelblick and Viscosity are OpenVPN wrappers that do not support connections of OpenVPN over socks proxies. This is not a limitation of our service. It's not even a limitation of OpenVPN for Mac OS X. It is just a limitation of the wrappers due to their programmers inability to support all OpenVPN features from the wrapper. Mac OS X users who need to connect over OpenVPN over TOR or over a proxy just need to use OpenVPN directly (installed by themselves, or using the version installed by Tunnelblick). Or they can use Shimo as an allegedly full-featured OpenVPN GUI (only for OS X 10.7 or higher). EDIT: please note that we did NOT test Shimo. Therefore, while we appreciate and welcome your criticism, we wish to reply that it's unfounded: our support to Mac OS X platforms IS complete. Kind regards