Staff

Hello! It's not a disconnection, it's a TLS re-keying through DHE. See also Perfect Forward Secrecy: https://en.wikipedia.org/wiki/Forward_secrec The re-keying occurs with overlapping windows: until the re-keying has not completed, the old key pair is used to encrypt the Data Channel, so no interruption of the throughput occurs and there's no time pressure. You can't disable this feature, otherwise you would suffer a disconnection every hour. You can lower the key expiration time, although we believe that one hour already provides a fair security. Kind regards

Hello, it is totally ok to use OpenVPN over SSH, although under normal circumstances (i.e. no traffic shaping) the performance will be lower than direct UDP, because of the overhead caused by a tunnel inside another tunnel and because OpenVPN must work in TCP. For this very reason, the symptoms you report are quite a proof that your ISP performs traffic shaping. Take note of the differences you have with the other VPN provider, it would be interesting to see why it does not get throttled. It might be because they use a different port, or because they don't use OpenVPN for example. Test also direct UDP connection to port 53, if you haven't already done so, and feel free to keep us posted. Kind regards

Hello! Very well. Just as a side note, about the failure you mention, if you're running a Linux system make sure that in the DNS Switch mode combo box (in AirVPN->Preferences->Advanced) you select "Renaming", not "Resolvconf" or "Automatic", in order to prevent any possible conflict between your up directive and the up directive that the client will need to accept DNS push through resolvconf-related script. Kind regards

Hello! If confirmed it will be fixed in the next Eddie version. Work-around: add the "up" directive as a custom directive, in "Custom" field of Eddie "AirVPN" -> "Preferences" -> "Advanced" -> "OVPN Directives" menu/window. Remember to add "script-security 2" as well, in order to tell OpenVPN that your own scripts are authorized. From OpenVPN 2.3.x manual: --up cmd Run command cmd after successful TUN/TAP device open (pre --user UID change). cmd consists of a path to script (or executable program), optionally followed by arguments. The path and arguments may be single- or double-quoted and/or escaped using a backslash, and should be separated by one or more spaces. The up command is useful for specifying route commands which route IP traffic destined for private subnets which exist at the other end of the VPN connection into the tunnel. For --dev tun execute as: cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip [ init | restart ] For --dev tap execute as: cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask [ init | restart ] See the "Environmental Variables" section below for additional parameters passed as environmental variables. Note that if cmd includes arguments, all OpenVPN-generated arguments will be appended to them to build an argument list with which the executable will be called. Typically, cmd will run a script to add routes to the tunnel. Normally the up script is called after the TUN/TAP device is opened. In this context, the last command line parameter passed to the script will be init. If the --up-restart option is also used, the up script will be called for restarts as well. A restart is considered to be a partial reinitialization of OpenVPN where the TUN/TAP instance is preserved (the --persist-tun option will enable such preservation). A restart can be generated by a SIGUSR1 signal, a --ping-restart timeout, or a connection reset when the TCP protocol is enabled with the --proto option. If a restart occurs, and --up-restart has been specified, the up script will be called with restart as the last parameter. The following standalone example shows how the --up script can be called in both an initialization and restart context. (NOTE: for security reasons, don't run the following example unless UDP port 9999 is blocked by your firewall. Also, the example will run indefinitely, so you should abort with control-c). openvpn --dev tun --port 9999 --verb 4 --ping-restart 10 --up 'echo up' --down 'echo down' --persist-tun --up-restart Note that OpenVPN also provides the --ifconfig option to automatically ifconfig the TUN device, eliminating the need to define an --up script, unless you also want to configure routes in the --up script. If --ifconfig is also specified, OpenVPN will pass the ifconfig local and remote endpoints on the command line to the --up script so that they can be used to configure routes such as: route add -net 10.0.0.0 netmask 255.255.255.0 gw $5 --up-delay Delay TUN/TAP open and possible --up script execution until after TCP/UDP connection establishment with peer. In --proto udp mode, this option normally requires the use of --ping to allow connection initiation to be sensed in the absence of tunnel data, since UDP is a "connectionless" protocol. On Windows, this option will delay the TAP-Win32 media state transitioning to "connected" until connection establishment, i.e. the receipt of the first authenticated packet from the peer. Kind regards

Hello! Since your VM is attached via NAT to your host you need to forward that very same port from your host to your VM. Virtualization software like VirtualBox nowadays handle very well port forwarding to VMs attached via NAT. Kind regards

Hello! ECC is not in OpenVPN main branch. Additionally, there are some unsolved questions and doubts, see Bruce Schneier for example, that we feel to take into highest consideration. We will take ECC into consideration only when it's in the main branch and if implemented without being based on parameters/constants which could have been manipulated by NSA to insert artificial weaknesses, i.e. only curves not based on the NIST recommended parameters etc., because they have been created by Solinas working for NSA and because there are some weird choices which trigger our... paranoia...? See also this interesting discussion: https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters Before going into ECC, you ought to be sure to use non-influenced by NSA elliptic curves. Ideally, you should also know how and to which extent NSA influenced the development and implementation of ECC through NIST standards and recommendations. Is there any reason for which you are going into ECC with such a light heart, almost "unconsciously" we would dare to say? Which curve parameters is the service you cite using? About performance, there can't be substantial operative difference between elliptic curves and integer discrete based ciphers for the Data Channel, and even less for the Control Channel, so any performance gain or loss can't be caused by that. Kind regards

Hello! Problem solved via ticket (of course we can't publish the code here ). Thank you very much! Kind regards

Hello, you should just put country Netherlands in the black list. Click "Countries" tab, select "Netherlands", click the icon "Blacklist". Kind regards

Hello, SkyGo is accessible (to subscribers) from all of our VPN servers provided that your system queries the VPN DNS. It is perfectly legal, you're a subscriber! Kind regards

Hello! Eddie client can run on OS X Mavericks and Yosemite only. Older OS X versions should run Tunnelblick, which is free and open source as well. Instructions for Tunnelblick are in the usual OS X page, in our web site click "Enter" -> "Mac OS X". You might even consider to upgrade your system, if possible. Kind regards

Hello! We will consider this option in the near future. In the meantime, you could connect both devices to the same server, provided that you don't need remote port forwarding. Just connect the devices to different ports to prevent conflicts. For example, device 1 to port 443 (UDP) and device 2 to port 80 (UDP). Kind regards

Hello @JWW, Eddie's "Network Lock" works on every browser and every program because it solves the Windows problem at its roots. What you cite is a Chrome extension, unrelated to VPN or other services. It can't prevent WebRTC leaks from other than Chrome programs. Currently we do not have developers for browsers extensions, but who knows, it could be an idea. Anyway, good to know that such an extension now exists. Previously available extension did not work properly. Kind regards

Hello, we do not detect any problem on Virginis. Maybe it's your node that can't reach it. Can you please try the alternative entry-IP address, port 2018? Kind regards

Hello! Problem detected, can you please try again now? Kind regards

Hello! In your case you need to pick specific, different servers, or at least connect each machine to a different port. Connecting the same account multiple times to different ports of the same server will not cause connection conflicts, but you will not be able to use remote port forwarding. For those who you use the client, the problem will be very similar. It may very easily happen that the client detects the same best server from different machines on the same local network. You should define different white lists on each machine. Eddie will then determine the best server from each white list and you will avoid any "collision". Kind regards

Hello! Please follow the instructions for DD-WRT. Click "Enter" from our web site upper menu then click "DD-WRT" icon. Direct link: https://airvpn.org/ddwrt Kind regards

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