Staff

Hello! After the TLS Authorization, authentication with the VPN servers is performed through double certificates and keys, not with some username and password. If you change your account password, that will not change the mentioned files because they are not generated from that password. The encryption keys for the OpenVPN Data Channel are negotiated at each new connection and every 60 minutes through Diffie Hellmann Exchange (DHE) - complying to Forward Secrecy. https://en.wikipedia.org/wiki/Forward_secrecy Authentication based only on login and password with a static key common to every user is not a setup to be taken into consideration if security is required on a VPN service. Not only it will not allow Perfect Forward Secrecy, but it poses some serious security risks: any man in the middle could decrypt your data simply by downloading the key; additionally, an attacker could impersonate the VPN server. Incredibly, some VPN services adopt this method. Kind regards

This is my exact same problem. I now know how to find the Entrance IP' but how do I find the PORT number? This info should be poart of the directions Hello! Our OpenVPN daemons listen to ports 53, 80 and 443. On the alternative IP address listening port is 2018, As specified in the DD-WRT instructions, the port numbers can be seen through the Configuration Generator as well. Some more information, if you're curious, is available in "Enter" -> "Specs" page, direct link https://airvpn.org/specs Kind regards

Does it mean AirVPN now collects any users data??? Hello! Nothing has changed. That was just identical in the old privacy notice. We repeat once again: the change in the notice is only in the language, to use a terminology that's consistent with the transposition of Directive 2009/136/EC in Italy. Kind regards

Hello! We're very glad to know it! Additionally, no reasons to worry even for the previous state, because you had no DNS leaks. Even the queries to your ISP DNS were tunneled. Kind regards

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