Staff

Hello! The TAP-Win32 adapter does not come up. Assuming that you have already checked that it is enabled according to the previous post, and that now you have just one TAP adapter, please make sure that in Control Panel->Administrative Tools->Services the DHCP Client Service is started and running. http://openvpn.net/index.php/open-source/faq/79-client/259-tap-win32-adapter-is-not-coming-up-qinitialization-sequence-completed-with-errorsq.html Also, what is your OS version? We're looking forward to hearing from you. Kind regards

Hello! Please follow the support instructions. If you already had a TAP adapter installed, you had to check whether it was enabled and not add another one. Anyway, please revert back to just one adapter, check that it is enabled, try a connection, browse to our website and verify that the central bottom box is green and saying "Connected". If it's red, please send us again the logs. We're looking forward to hearing from you. Kind regards

Hello! The TUN/TAP adapter does not come up. Apparently, either it is not installed or it is disabled. Please make sure that it is enabled: On Windows XP: Open Control Panel-->Network and Internet connections-->Network Connections. Right-click on "TAP-Win32 Adapter V9" and select "Enable". Windows Vista: Open Control Panel-->Network and Internet-->Network and Sharing Center-->Manage network connections. Right-click "TAP-Win32 Adapter V9" and select Enable. Windows 7: Open Control Panel-->Network and Internet-->Network and Sharing Center-->Change Adapter Settings. Right-click on "TAP-Win32 Adapter V9" and select Enable. If you find that the TAP adapter is already enabled, select "Disable", apply the change, then select "Enable". If you find that you have NO TAP-Win32 adapter, something went wrong with the OpenVPN installation (maybe you did not authorize the installer to install the adapter driver). You'll need to install an adapter: please select "Start"->"All Programs"->"OpenVPN GUI"->"Utilities"->"Add a new TAP Virtual Ethernet Adapter". If the operation fails, you'll need to completely uninstall OpenVPN and re-install it, making sure to authorize the installation of any driver. Please feel free to let us know whether the above solves the problem. Kind regards

Hello! Currently you can have a 10% discount on additional accounts on any plan (except when the 1st account is subscribed to a 4 days trial). Please do not hesitate to use the "Contact us" form in order to require such a discount for multiple accounts. Kind regards

Hello! It looks like the client can't contact airvpn.org as soon as the connection is established. Can you please try to add the following line to your hosts file: 46.105.19.36 airvpn.org We're looking forward to hearing from you. Kind regards

Hello! That's correct, either you use OpenVPN directly, the OpenVPN GUI or the Air client. The Air client is an OpenVPN wrapper, so you must not have OpenVPN GUI already running when you initiate a connection with the client. To begin with, just go with the Air client and send us the logs in case of any issue. In order to do so, please right-click on the Air dock icon, select "Logs" and click on "Copy to clipboard". Then paste here. We're looking forward to hearing from you. Kind regards

Hello! This needs to be clarified by Microsoft. We don't know how Comodo DNS servers work and we are unaware about their privacy policy. Google DNS are excellent for performance and net neutrality, but they pose too many privacy issues. You might like to check DNS servers maintained by German and Swiss Privacy Foundations: http://server.privacyfoundation.de/index_en.html and Telecomix DNS, a quite interesting project: http://werebuild.telecomix.org/wiki/DNS Kind regards

Hello! It's just fine, our servers DHCP-push the VPN DNS IP address. Kind regards

Hello! AirVPN is based on OpenVPN. You can't renounce to it if you wish to connect to a VPN server. If you can't run OpenVPN on your Windows7 machine (maybe you don't have administrator access?) you'll need to setup a gateway (which connects to the VPN) for that Win7 computer. Kind regards

Hello! The trigger of the leak can be a matter of discussion for the Microsoft customers' support. Apparently, any delay in a DNS query response inside the tunnel (or in general from a network interface) may trigger another DNS query from another interface. Apparently this is a consequence of a very bad design... but perhaps Microsoft may be able to give some justification for this mess. Only DNS queries inside the tunnel are allowed (rule "Allow TCP or UDP In/Out From In [AirVPN] To MAC Any... etc.). All the others are dropped by Comodo block rule. Kind regards

Hello! That's correct, no DNS leak. On Windows 7, please add to your hosts file the following line: 46.105.19.36 airvpn.org in order to allow the Air client to resolve airvpn.org for VPN connections. Kind regards

Hello! Can you please tell us in which server(s) you have this problem? Kind regards

Hello! It makes no difference: all the DNS queries outside the tunnel are blocked by the Comodo block rule, so there can't be and leak. Because the DNS queries are sent only inside the tunnel toward the TAP-Win32 DNS IP address. DNS queries outside the tunnel are blocked by: Block And Log IP In/Out From MAC Any To MAC Any Where Protocol Is Any Kind regards

Hello! Yes, in that order they are just fine! Kind regards

Hello! We're very glad to know that the problem is solved. No, it's not possible (see below). The "culprit" is Windows. Windows lacks the concept of global DNS, so each card can have its own DNS server IP addresses. The DNS server IP configured (DHCP pushed) on your physical interface is 192.168.0.1. So in every case of a DNS query which does not "obey" to the routing table, the query is sent to your router (configured to act as a DNS server), and not blocked by Comodo (because we allow communications in the home network, which is vital, otherwise it would not be possible to communicate with the router). Then the router sends the unencrypted query to your ISP DNS. By blocking communications in your home network toward port 53 UDP the problem is solved because DNS queries can go only to that destination port. Other options to block the leaks are forbidding DHCP DNS push from the router (just configure your WiFi card with any fixed primary and secondary DNS you like, so that any leak will be blocked by Comodo by the already existing rules) or blocking with Comodo UDP packets toward 192.168.0.1 port 53 (remember, in this case, to modify this rule if you change the address of the router). Thank you! Kind regards

Hello! Currently an outage in a high volume Leaseweb core network router may cause low bandwidth availability on Lyra and Leonis. We will keep you updated. UPDATE 15.23 CET+1 - Problems on Lyra and Leonis appear to be fixed. We are currently facing issues with Leporis (low bandwidth). UPDATE 15.32 CET+1 - High volume router crash is affecting Leporis, Leonis, Lyra. You may most probably notice low bw on these servers. UPDATE 15.35 CET+1 - High volume router stabilized. While redundancy is being restored, the problem should vanish. UPDATE 15.59 CET+1 - All problems are solved Kind regards

Hello! Yes. Please check also that the DNS push from our VPN servers is successful, you should see the same 10.4.0.1 DNS server IP address on your TAP-Win32 adapter (Windows lacks the concept of global DNS servers, it needs that DNS servers are specified for each adapter). Kind regards

Hello! Either you have a DNS leak (which is a privacy risk) or you're tunneling DNS queries to your ISP DNS (which is not worrying). About the first case, your computer can communicate to your router, so please check whether DNS queries are sent to your router IP address. Chances are that your router then queries your ISP DNS servers (obviously out of the tunnel), causing the leak. If it's the case, just replace your rule pertaining to your Home network in order to block packets toward port 53 UDP with 2 or 3 different rules: For example: Allow TCP In/Out From In [Your Home Network Zone] To In [Your Home Network Zone] Where Source Port Is Any And Destination Port Is Any Allow UDP In/Out From In [Your Home Network Zone] To In [Your Home Network Zone] Where Source Port Is Any And Destination Port Is Not 53 OPTIONAL, only if you need it: Allow ICMP In/Out From In [Your Home Network Zone] To In [Your Home Network Zone] Where ICMP Message Is Any Kind regards

Hello! That's perfectly normal, it's how TCP works. Kind regards

Hello! Please see the permanent links in the announcements section of the forum in order to secure your connection according to your OS. We provide instructions for Comodo (Windows), pf (*BSD, Mac OS X), ipfw (*BSD, Mac OS X), iptables (Linux). Kind regards

Hello! Mail received and we confirm that Comodo configuration is all right. The Google DNS you see in the test are fine. You should never see your ISP DNS IP addresses. Should you see them again, further tests will be necessary. Kind regards

Hello! Are you sure you're still connected when it happens? What is your OS? Can you please check whether it's a DNS problem? When the problem occurs, try to browse to: https://46.105.19.36 If you can reach our website, then (assuming you're still connected to a VPN server) it's probably a DNS problem, the causes of which will have to be investigated. Furthermore, is there anything helpful in the client logs? Can you please send them to us when the problem occurs? Kind regards

Hello! We would recommend that you use our DNS, because after our internal resolution against censorship and for internal services, the queries will be sent to Google DNS anyway. In order to determine it please see here https://airvpn.org/specs Your system can send DNS queries to Google in two ways: directly, in which case they are going out unencrypted (and that's not good) or tunneled through our servers, in which case they go out in the encrypted tunnel, you will not be using our DNS but you won't have leaks anyway. In your specific case the test does not tell anything useful: you can't discern whether the detected Google DNS servers are reached by unencrypted queries, encrypted queries or through our DNS. Please note that our servers will always push DNS to clients. However a system can be forced to use another DNS and ignore the push (this might be your case). Kind regards

Hello! The Global Rules showed in the provided link block DNS leaks. If your ISP DNS IP addresses appear in the leak test, either there's actually a leak (therefore some mistake in the rules or network zones), or your provider has public DNS and your device is forced to use them. In this case, the DNS queries are tunneled and your provider will see the queries coming from our VPN server, so the leak is not real. Please feel frees to end us your Global Rules and the definition of you Network Zones for a check. Kind regards

Hello! OpenVPN can't access the TAP-Win32 adapter. Please make sure that it is enabled: On Windows XP: Open Control Panel-->Network and Internet connections-->Network Connections. Right-click on "TAP-Win32 Adapter V9" and select "Enable". Windows Vista: Open Control Panel-->Network and Internet-->Network and Sharing Center-->Manage network connections. Right-click "TAP-Win32 Adapter V9" and select Enable. Windows 7: Open Control Panel-->Network and Internet-->Network and Sharing Center-->Change Adapter Settings. Right-click on "TAP-Win32 Adapter V9" and select Enable. If you find that the TAP adapter is already enabled, select "Disable", apply the change, then select "Enable". Please feel free to let us know whether the above solves the problem. Kind regards