Staff

Hello! We have momentary problems with micro-routing to Italy, we expect to have them solved in few days. Kind regards

Hello! All traffic from/to your system is already tunneled, including the traffic from/to an e-mail client. Our OpenVPN servers push routes to create a routing table that tunnels everything. Your OpenVPN client reads the pushes and modify the routing table accordingly. Activate "Network Lock" in our client Eddie to prevent any leak, for example in case of unexpected VPN disconnection. Kind regards

@flat4 Hello! The first possible reasons that come to mind: 1) Your ISP performs traffic shaping against UDP and/or OpenVPN 2) You have a tool in your router or in your computer that de-prioritizes UDP packets. In both cases, wrapping OpenVPN inside an additional TLS tunnel fixes the issue. However, if the problem lies in your system and you manage to solve it, you will have better performance with UDP direct connections than with OpenVPN over SSL, because of the overhead caused by two tunnels instead of one, and the important fact that OpenVPN is forced to work in TCP when it must connect to stunnel (since UDP can't be supported by stunnel). Kind regards

@hashswag Hello! Another option to be taken into consideration is that on your Windows system some packet inspection/filtering tool or "QoS management" is running. Inspecting encrypted packets is not only useless but it might slow down considerably the throughput. You could check that. An additional idea/speculation is that the QoS tool gives higher priority to TCP and de-prioritizes UDP. That would explain the performance gap you observe between UDP direct connection and "OpenVPN over SSL" connection: the performance hit due to double tunneling and forcing OpenVPN to work in TCP would be much lower than the one caused by the tool. You could also measure the performance in TCP direct (without an additional SSL tunnel) to gather an additional clue. Kind regards

Hello! Please see here: https://airvpn.org/topic/3773-pls-help-strange-logs/?do=findComment&comment=3784 in particular from "A replay attack is..." until the end. Kind regards

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