Staff

Hello! There are no DNS leaks on Linux. Even if your system queries different DNS servers, DNS queries are anyway tunneled. A DNS leak is when a DNS query is sent unencrypted outside the tunnel and this is not your case. A possible explanation is that your system does not properly change nameservers because resolvconf package is not installed (but it should be pre-installed in any Ubuntu version). In this case, in "AirVPN" -> "Preferences" -> "Advanced" try to select "Renaming" in the "DNS Switch Mode" combo box. If the problem persists please send us the content of your /etc/resolv.conf file while the system is connected to some VPN server. Kind regards

Hello! The problem: . 2015.02.19 12:15:47 - OpenVPN > [uNDEF] Inactivity timeout (--ping-exit), exiting Please make sure that no firewall (either on your computer or router) blocks UDP packets and/or OpenVPN packets. In case that your ISP has started blocking UDP, please try a connection in TCP. You can change connection mode in our client Eddie menu "AirVPN" -> "Preferences" -> "Protocols". Please try TCP port 443, but also UDP port 53. Kind regards

Hello, we remind you that this years old bug has been patched since a long ago in our OpenVPN versions. You can find them (for Linux, Windows and OS X Mavericks/Yosemite) inside our client packages, if you wish to test. Kind regards

Hello! Please make sure to run OpenVPN or OpenVPN GUI with adminstrator privileges. You might also like to use our free and open source client Eddie. Kind regards

Hello! We are experiencing problems with our micro-routing server in Italy and we are investigating. Kind regards

Hello, in our client Eddie, is "Force DNS" ticked in "AirVPN" -> "Preferences" -> "Advanced"? Kind regards

Hello! Please see here: https://en.wikipedia.org/wiki/Latency_(engineering) in particular https://en.wikipedia.org/wiki/Latency_(engineering)#Packet-switched_networks You should prefer servers with lower latency. The lower the better. Kind regards

Hello! Eddie runs on OS X Mavericks and Yosemite. Older OS X versions (if you can't or don't want to upgrade) should run Tunnelblick which is free and open source as well. Kind regards

Hello! Changes in latency from your node to different servers in different datacenters with different providers is a symptom of a change of peering or routing by your ISP or by one or more of your ISP ISPs, or maybe some technical problem inside your ISP network or inside some of your ISP ISPs network. That's because the likelihood that three different datacenters (our four UK servers are in three different datacenters) with different tier 2-1 providers have simultaneously the identical problem is astronomically low. Kind regards

Hello! In our service OpenVPN works in routing mode, so tun interface is necessary, not tap. For differences between routing and bridging (from which you will also understand why we picked routing) please see here: https://community.openvpn.net/openvpn/wiki/BridgingAndRouting Kind regards

Hello! No, it's not normal... can you please make sure that you shut down Eddie (the client) properly before you shut down Windows? Kind regards

Hello! As you may have seen, all of your requests have been implemented in Eddie 2.8.8. Enjoy AirVPN! Kind regards

Thank you very much for the report! Of course, it will be fixed in the next release. Kind regards

Hello! While on the client you see latency from your node to each VPN server, in the Status page you see the time required by your browser to get a small file from the server with an HTTP GET request. Therefore, the times you see on the Status page are much bigger than latency. However, they still have their usefulness as a relative evaluation. Kind regards

Hello! This is just a clarification that could be useful for some casual Linux user reading this thread: Linux does not suffer any WebRTC leak so no intervention at all is necessary. Kind regards

Hello! Eddie sets 10.4.0.1 as primary DNS of all the system network interfaces, do you do the same? Compare the status of the computer network interfaces with Eddie "Force DNS" method and with your method. There must be some difference to justify the different behavior. Compare all network cards with command "ipconfig /all" issued from a command prompt. Kind regards

Hello! In order to determine whether the routes check failure is correct or not try to disable the control by unticking "Check if the tunnel effectively works" in "AirVPN" -> "Preferences" -> "Advanced". Connect again, browse to airvpn.org and verify whether the central bottom box is green or red. If it's green, the check outcome was really wrong, just leave routes check disabled. In this case you might like to activate "Network Lock", to avoid having to manually check each time if the connection was successful or not. If it's red, then the routes check failed correctly and further investigation is necessary. Kind regards

Hello! We're happy to hear that. Who/what does not put IP 10.4.0.1 in where? Client Eddie can set 10.4.0.1 as primary DNS server IP address of all network interfaces by ticking "Force DNS" in "Preferences" -> "Advanced". Kind regards

I see last anwser to this topic from stuff is older than a year... Hello, please disregard this thread and read here: https://airvpn.org/topic/12636-faq-referrals/ We're going to lock this thread because it is obsolete. Kind regards

@aldebaran Hello! Since you run Eddie, if you don't want to go into details, you could just go to "AirVPN" -> "Preferences" -> "Protocols", select some OpenVPN over SSH mode, click "Save" and re-connect to some VPN server. For your purpose, we would also recommend that you test OpenVPN over SSL. In Eddie "Protocols" tab, this is called "SSL Tunnel - Port 443". Technically, OpenVPN over SSL can be less efficient than OpenVPN over SSH [sTRIKE THROUGH: INCORRECT], but in case that your ISP does not shape only port 443 (because it does not want to make the shaping appear to customers using https) and port 80 (for http) then OpenVPN over SSL can provide higher throughput than OpenVPN over SSH (we do not provide SSH to port 443). Kind regards

Hello! Confirmed. In reality, it probably never worked, it was only the old testing code that was inadequate to force the leak. As you may have already seen, now ipleak.net web site is able to force a leak with Chrome regardless WebRTC Block extension is active or not. Therefore, without firewall aid (our client Eddie Network Lock for example), we are currently unaware of any method to effectively prevent such leaks with Chrome. If one does not prevent such leaks with Network Lock or anyway methods that are out of Chrome, we think that it is very important NOT to use Chrome when inside the VPN. Kind regards

Hello! Wise words. On top of that, we would like to underline that developer has made remarkable efforts to keep the client flexible for users who are "evolving" to advanced competence, with subsequent higher requirements, but still do not feel to leave Eddie which provides several commodities that can be appreciated even by quite advanced users. About this topic, keep in mind that seven different "Events" can be defined in Eddie. Events can occur at Eddie start, Eddie shut down, Session start, Session end, VPN Pre, VPN up and VPN down. For each event, in any combination, user can tell Eddie to execute something, with or without arguments. For each event, Eddie can be instructed to wait for the event end, or go on without waiting. This is a useful addition for a very wide variety of purposes, in addition to the option to customize completely OpenVPN directives from inside Eddie as well. We are confident that "Events" provide a fair balance between advanced usage requirements and demands to not allow the client to become too heavy as well as maintaining the option to run it without installation. The quickest way to define events is through the GUI, at "AirVPN" -> "Preferences" -> "Advanced" -> "Events". Kind regards

Hello! Confirmed. Also, ipleak.net code has been updated (just like other sites did) to show that this Chrome extension does not work properly. Code update to show the leak more effectively was necessary for all sites, because the demo code was different a couple of days ago. Kind regards

Hello @Opayq, thanks for the info, it looks relevant, because it is not an expected behavior and it will need additional investigation. In the meantime your way to kill both processes is fine, perfectly legitimate. Kind regards

Hello! Yes, because our service supports remote port forwarding. You can forward ports not lower than 2048, but you can also remap remotely forwarded ports to any local port. Please see here: https://airvpn.org/topic/9161-you-provide-remote-port-forwarding-what-is-it Kind regards