Staff

Hi zhang888 and everybody, disclaimer: this message is written by only one person of the staff, while other persons are still investigating. We confirm that: - in VPN servers we use Diffie-Hellman 4096-bit keys - in VPN servers we do not use the same prime numbers used by millions of web sites - our web site does not support DHE_EXPORT That said, we are still investigating whether a TLS downgrade on the Control Channel is possible and, even if it was, how to affect DHE to force one of the sides to a DHE_EXPORT downgrade up to 512 bit. References which we have started from: Theory: https://weakdh.org/imperfect-forward-secrecy.pdf Practice: https://weakdh.org/logjam.html At the moment, we operate from a very conservative/paranoid approach so we are not ruling out 100% anything, but we can at the moment state that: - web site is totally secure on server side About OpenVPN in our setup: - Attack I is obviously not possible, since it requires weak DH 512-bit primes in the first place - Attack II (and therefore Attack III) appears infeasible, for different premises which are not met: "The server, in this case, only needs to support DHE_EXPORT cipher suites or use 512-bit parameters in non-export DHE ciphers. The client must be using the TLS False Start extension; that is, the client sends application data before receiving the server's Finished message in the TLS handshake." The question is whether it's possible to think about a mutant, specific attack form explicitly aimed to OpenVPN Control Channel to affect DH keys for Data Channel encryption. We will keep you updated of course. We are focusing on OpenVPN because even if you use it over SSH or stunnel, TLS+DHE downgrades on them appear to be not essential since your main "defensive" layer remains on the underlying OpenVPN. Kind regards

We owe you a lifetime supply of the finest non-industrial beers. Kind regards

We don't understand this discussion so you might like to clarify things between you three (no flames please). We do however understand this point, once again you claim that port forwarding does not work on LA servers, so we would like to confirm once again that port forwarding works just fine on Los Angeles servers. Kind regards

Hello! The tun/tap interface (virtual network interface used by OpenVPN) does not come up... please try this: https://airvpn.org/topic/8320-solved-connects-but-ip-doesnt-change-on-windows-server-essentials-2012/?do=findComment&comment=8321 Also, upgrading to Eddie 2.9.2 might help with Windows Vista/7/8, because it will use a new driver for the interface which fixes various problems in Windows Vista/7/8. Kind regards

Hello, Tor proxy (just like any socks or http proxy) does not support UDP. OpenVPN will necessarily work in TCP. Please see also https://airvpn.org/tor Kind regards

Hello, do you get this error message even if you shut down Eddie with its own "Exit" option? Kind regards

Ok, great! What is your firmware? Did you compile stunnel by yourself for your router or is it an already available version? Kind regards

Hello! Since our servers will accept a variety of ciphers for SSL this is possible by configuring stunnel. However, configuring parameters for stunnel is currently not implemented in Eddie. Please see for example: https://www.stunnel.org/pipermail/stunnel-users/2013-February/004112.html Anyway, you probably don't need to bother about that. Nowadays computer CPUs are so powerful that they are not loaded at capacity by the current stunnel and OpenVPN ciphers you're using (well, it also depends on how much load they have from other tasks...). Kind regards

Hello! By default, all of your system traffic is routed inside the VPN tunnel once your system is connected to the VPN itself. If we understand correctly the problem, you would need to have only some traffic to certain web sites routed outside tunnel, so that those web sites see your real IP address and your traffic is not encrypted by the tunnel (i.e. not tunneled at all)? If so (but please make sure that we understood correctly!) you can do so in Eddie client menu "AirVPN" -> "Preferences" -> "Routes". Make sure that the combo box "Not specified routes go:" is set to "Inside the VPN tunnel". Then add in the window (by clicking the "+" icon) all the IP addresses of those web sites for which you wish the traffic is not tunneled. Action for them is "Outside the VPN tunnel". WARNING: all traffic to those IP addresses will not be tunneled. Not only "web traffic". Kind regards

Hello! Currently not, it's not meant as an alternative to Network Lock. In case of server switch or unexpected disconnection Eddie restores default gateway and nameservers, and only after that it tries a new connection. Kind regards

Hello! Because that's the date of the last changes, bugfixes and addition of new features. In April Eddie 2.9.2 Experimental exited the alpha testing and entered the beta testing. A few days ago beta testing was closed and Eddie 2.9.2 Experimental was promoted to stable. Kind regards

Hello! It's a bug (or more than one bug) in Mono. In the future, Eddie developer will consider to drop Mono and develop a GTK version. However at the moment this is not planned, we'll need a specific resource allocation for this task. Kind regards

Hello! IPv6 detection bug with error "Could not find a part of the path "/proc/sys/net/ipv6/conf/all/disable_ipv6" on some distributions will be fixed in version 2.10. Can you please elaborate? Can you show the logs about that and/or elaborate? Eddie for Linux can't disable IPv6. With "None" option it will not show the warning message. Eddie will set "None" in "IPv6" combo box after it has displayed the warning message. Thank you! Kind regards

They are the very same version, totally identical byte by byte. Kind regards

Hello! Important: please note that under Linux Eddie can't disable IPv6 (it can do that only in WIndows and OS X). If you activate "Network Lock" Eddie will set ip6tables to block outgoing IPv6 packets. This thread is followed by Eddie developer, so the bug(s) you've found are being noticed. Kind regards

Thank you very much for your quick reply. Unfortunately, I have an unattended client and I do need to save the login details since at times nobody is around during startup. Are there any plans to implement this or have there not been enough requests? At the very least, Eddie could set more restrictive file permissions on the profile automatically, that would be fairly simple, although I would prefer the more secure way of using the specific OS APIs to handle this. Hello! No requests at all but this the correct way hands down, you're right. Kind regards

Hello! Thank you for your great feedback! Yes, just like browsers if you don't use a master password to encrypt all other passwords. This option is not currently available in Eddie. EDIT: the AirVPN.xml file although belonging to root:root is actually readable by every user, you're right. This needs to be fixed. You might like to not tick "Remember" in the login window: in this way the client will not store username and password and you can enter them anytime you run Eddie. Kind regards

Good! That could be due to the new tun/tap driver for Windows, do you run Windows? Kind regards

Port forwarding works just fine on Los Angeles servers. Kind regards

Hello! We released Eddie 2.9 as stable: https://airvpn.org/topic/14256-eddie-29-available Any pending issue in this topic will be addressed to version 2.10 experimental soon: we can't delay anymore all bugfixes between 2.8 and 2.9. Kind regards

Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.9. 2.9 version is compatible with several Linux distributions. For very important notes about environments, please read here: https://airvpn.org/forum/35-client-software-platforms-environments Eddie 2.9 includes bug fixes and changes meeting users' requests and preferences. It includes additional options for Network Lock to enable communications inside LAN and to allow ICMP, a new, reliable method to check DNS, an option for Windows and OS X to disable IPv6, connection to authentication servers via IP addresses instead of names and much more. Please read the changelog: https://airvpn.org/services/changelog.php?software=client&format=html Upgrade is strongly recommended. Just like previous version 2.8, Eddie implements direct Tor support for OpenVPN over Tor connections. Eddie makes OpenVPN over Tor easily available to Linux and OS X users: no needs for Virtual Machines, middle boxes or other special configurations. Windows users will find a more friendly approach as well. This mode is not handled anymore as a generic connection to a socks proxy, but it is specifically designed for Tor and therefore solves multiple issues, especially in Linux and OS X, including the "infinite routing loop" problem (see for example http://tor.stackexchange.com/questions/1232/me-tor-vpn-how/1235#1235 ) As far as we know, Eddie is the first and currently the only OpenVPN wrapper that natively allows OpenVPN over Tor connections for multiple Operating Systems. https://airvpn.org/tor We recommend that you upgrade Eddie as soon as possible. Eddie 2.9 for Linux can be downloaded here: https://airvpn.org/linux Eddie 2.9 for Windows can be downloaded here: https://airvpn.org/windows Eddie 2.9 for OS X Mavericks and Yosemite only can be downloaded here: https://airvpn.org/macosx PLEASE NOTE: Eddie 2.9 package includes an OpenVPN version re-compiled by us with OpenSSL 1.0.1k for security reasons and to fix this bug: https://community.openvpn.net/openvpn/ticket/328 Eddie overview is available here: https://airvpn.org/software Eddie includes a Network Lock feature: https://airvpn.org/faq/software_lock Eddie 2.9 is free and open source software released under GPLv3. GitHub repository https://github.com/AirVPN/airvpn-client Kind regards & datalove AirVPN Staff

Can you confirm that the recommended solution works? Kind regards

Hello, assuming that you can enable Network Lock, all Eddie versions since 2.5 should be blocking "WebRTC leaks". Eddie 2.5 was the first version to feature Network Lock. https://airvpn.org/services/changelog.php?software=client&format=html Kind regards

Hello, names provided by our DDNS are *.airdns.org. DynDNS is a service offered by Dyn Corp. and is another DDNS. There's no way they can use *.airvpn.org names, of course. theemim.airvpn.org resolves into Theemim entry-IP address according to the convention "server_name.airvpn.org" The doubts arose from that other IP address cited in the first message, 91.220.163.33. However, as Zaroad pointed out, the whole range 91.220.163,0/24 could be blocked by Malwarebytes. We just fell in that range with the IP addresses of this brand new server, not very lucky, but anyway we saw (probably you remember that) that Malwarebytes blocks enormous IP ranges for just one problematic machine: for example they blocked our frontend in Luxembourg as source of malware, and they confirmed, when inquired about that, that the block was correct because in that datacenter a different machine was spreading malware. Not exactly a fine grain defense for their users... EDIT: this is a funny thread from 2012 https://airvpn.org/topic/5061-mbam-webip-blocking-module-blacklist-airvpn-ips Given all of the above, we think than any person reading this thread can easily draw some conclusions about Malwarebytes. Kind regards

Thanks Zhang888, but it's not possible for us to get the whole /20 /21 subnet, because it is assigned to someone else and anyway it would be irrationally expensive for us for Spain (remember that Spain needs 20 Mbit/s for 35 customers at any given time...). We got "just" a /24 subnet RIPE update (and we actually use only of a portion of that). This one (46.182.35.0 - 46.182.35.255) is entirely and correctly geo-located to Madrid, so Bitcanal in our opinion operated correctly. Is there any reason (limited resources?) for which not even a /24 subnet is scraped after almost a year or even never (if you know) when two NETNAME are in the same AS? Only "big" subnets such as /20 are scraped? If so, geo-IP database maintainers are even more unreliable than we suspected, because with IPv4 exhaustion we think it's not so rare to put two NETNAME records with the same AS. Of course, if the remaining part of the /20 /21 subnet could agree to renounce to their NETNAME, then... but we think it's difficult, because they have another datacenter in Portugal and they probably need that. Kind regards