Staff

@anonuem Please follow the instructions: click "Other versions" > "Experimental" before downloading. By default the latest stable version is downloaded. Kind regards

Hello! No misunderstandings, we confirm our previous reply. If you run OpenVPN you can stop a connection by killing directly the process by sending a SIGHUP etc. If you decide to talk with OpenVPN Management only, you should see that the same happens. We could see if some trick or some more invasive behavior can be inserted but this is not a priority and anyway it's a matter that stays essentially in the hands of Eddie developers - currently one of the guidelines says more or less "keep system invasions as low as possible". Kind regards

Why do you consider a limitation an operation that is out of the scope of an OpenVPN frontend and that just takes 10 seconds? Only you know your system so only you can do this operation in the correct way. And if you don't know your very own system, how are Eddie developers supposed to know it? An invasive operation like that, as well as any other modification to system settings surviving a reboot, can potentially be a catastrophe on remotely controlled machines, on any machine which performs firewall operations at boot, and it is not what the overwhelming majority of users of an OpenVPN frontend want (just compare the thread pertaining to failure of Eddie 2.10.3 to restore DNS settings - and that was just a glitch which occurred under very particular circumstances). If you want a firewall, you need to use a firewall. The warning you cite was put exactly for the purpose: it was a momentary flaw that needed to be fixed in some future build, as it has been done. Kind regards

Hello, we were aware of CVE-2016-5696 and we had already applied the recommended, "trivial" patch. The fact the all of our communications are encrypted resolved any problem radically, except the fact that it was still possible to try to "reset" a connection, which would have been very annoying of course. Kind regards

It looks good as it is now. Eddie talks with OpenVPN Management for any operation with OpenVPN. It does not perform other operations that would pose problems to restore system settings or any other unexpected problem. Kind regards

We do not use VPS. only dedicated servers. 71.19.249.195 is one of our IP addresses and it is assigned to a server (Cetus) that is connected in a eSecureData datacenter in Vancouver. Cetus is an AirVPN server. You are not obliged to trust the datacenter which the server is connected in . You can use end-to-end encryption and perform "partition of trust". Evaluate according to your threat model. Some notes about that are here: https://airvpn.org/topic/54-using-airvpn-over-tor/?do=findComment&comment=1745 No, totally incorrect. That's an IP address assigned to Cetus. It is not used to route any traffic from any other server. We have six servers in the aforementioned datacenter. And yes, each server is in some datacenter, did you think that we connect our servers to residential lines? Even this absurd case would make no difference, data would transit anyway in some ISP infrastructure, and then some other ISP infrastructure and so on, until they arrive at destination. Yes. You need to resolve all dependencies first. Mono is mandatory with the installing version. Kind regards

This is explicitly excluded. We can't "promise" a permanent Network Lock because we can't know in general what your system does during the boot and for some other problems we explained in the past. Considering that a permanent Network Lock consists of a couple of rules that you can implement in 10 seconds, this request is unreasonable. Also have a look at some future version of the Pocket Firewall for Windows:https://airvpn.org/topic/18782-project-windows-pocket-firewall/ Kind regards

Yes, even in tickets, and above all we have never been able to reproduce it. Kind regards

A very rare Windows bug since it has never been reproduced in our machines. Reported anyway by another user who solved it with system re-installation (not very useful...), probably a broken update consequence. Hopefully solved by new Windows Filtering Platform used in the Eddie 2.11.x versions. Kind regards

Hello, excellent, you solved it by yourself. Anyway you can just not bother about your local IP address sent out by WebRTC etc., it's not significant. The real leaks from any process binding to the physical network interface are prevented by Network Lock. Kind regards

Please note that in the screenshot your public IPv4 address does not appear anywhere. You are talking about the local IP address of your machine inside your local network. Nothing wrong or worrying therefore. Kind regards

False. In case of a kill without grace, Eddie restores DNS settings and firewall rules at the next run. Or you can just set your DNS manually and re-set firewall rules. Both these operations take 20-30 seconds. Re-installing a whole Operating System for a 30 seconds job is totally crazy. Thread locked, enough is enough. Kind regards

Yes, this has nothing to do with the previous papers you linked. None of the cited techniques becomes necessary. Which is, unfortunately, excellent for the attacker, since those techniques don't work effectively. Once the VoIP conversation origin is known, the attacker has so many options. It could for example attach black boxes on the VPN server, so that the VPN company can't realize that the server is wiretapped and the boxes can be controlled directly by the attacker, at the same time preventing any possible judicial reliability problem that could arise from data reported only by the datacenter equipment. Then, the attacker hopes that the target will re-connect again to the same VPN server and connect again to the same destinations via VoIP or any other ascertained protocol/application etc. This is a situation where the attacker controls all the needed network segments AND knows one of the origin nodes and the destination node already. It can do nothing to identify the target with the available data at that moment, but if the target re-walks the same path, chances that it will be identified are significant if partition of trust is not performed. We have discussed how to defeat such an attacker years ago with what we trivially called "partition of trust". Kind regards

First of all, this was a quite popular mistake that took place in the academic world between approx. 2010 and 2014. Luckily in 2014 the fallacy of tons of such studies and presumed fabulous attacks based on web fingeprinting, netflow etc. have been revealed as a gigantic castle in the sky caused by outstanding flaws in the papers you cited and wrong assumptions. Just like any sector operator already knew by experience. Luckily most of those papers remained in pre-print and never passed any peer-review for publication in any scientific magazine and such. The problem is always the same in the academic world: "publish or perish". Another problem is that in the IT, sometimes a pre-print paper is taken seriously before a proper peer-review. See also here to get aware of the bias and flaws of tons of such researches: https://blog.torproject.org/blog/traffic-correlation-using-netflows And an independent confirmation of the fundamental fallacy of such studies: http://www1.icsi.berkeley.edu/~sadia/papers/ccs-webfp-final.pdf In your specific case, you are even below the minimal attack requirements of the papers you cite, because you assume to monitor only "one side", i.e. an insufficient segment of the network. Not that this is very important, because even if you raise your requirements, the attack is doomed to fail anyway. See the first article linked above. It is not possible to hide messages in an IPB forum from a user point of view, this option is not available, we're sorry. However, we inform you that ad hominem attacks are not allowed on our forums and will cause limitations to the infringing account. Traffic encryption is one of the highest entropy traffic available (one method to block Tor and VPN services is early detection of high entropy traffic and subsequent packets dropping). Of course a VPN, or Tor, increases entropy of your traffic only from your node to the final VPN or Tor exit node, so end-to-end encryption should be mandatory as well. You might also consider padding to prevent potential identification of traffic type INSIDE the tunnel, in spite of the traffic entropy. Although currently such techniques are not yet very successful, they were applied already 15 years ago, then dropped, and now re-considered - so they are continuously refined. Maybe it's too early anyway to take action against them but consider your threat model. Remember anyway that traffic entropy is not strictly related with the discussed issue, and could not help at all. Partition of trust may become necessary. Again, you need to define your threat model. Kind regards

P.S. We changed the topic title because the previous one was demented.

It is minimized. Click the tray icon and select "Show main window". Kind regards

Hello! Developer boss found the combination of Mono behavior and openSUSE default setting that is causing this problem. When "ping" is used in Mono, it tries first of all to resolve the hostname: https://github.com/mono/mono/blob/master/mcs/class/System/System.Net.NetworkInformation/Ping.cs#L243 The hostname resolution is triggered by that "GetNonLoopbackIP". If it fails, the whole ping fails. Now, in openSUSE standard installation, strangely the hostname is undefined in /etc/hosts, and it can't be resolved. By fixing this openSUSE glitch you will also fix this problem with Eddie. Just add in your /etc/hosts file (you'll need root privileges) the line: where is for example the IP address of your system main network interface in your local network. The fact that Mono wants to resolve hostname at each ping should anyway be considered a Mono bug, probably. Kind regards

Hello! When /etc/resolv.conf does not exist Eddie DNS Switch Mode "Renaming" can't work. On top of that, Eddie will send a SIGTERM to OpenVPN and give up everything. This particular case will be covered starting with Eddie 2.11.4 beta (due to be released during this week), where /etc/resolv.conf handling will be greatly improved. Kind regards

Hello! We can reproduce this issue and at a first glance it might be a Mono 4 bug. To circumvent it, do not try to connect to any server until the "latency tests" are complete. To see the status of such tests click the "Stats" tab and look at "Pinger stats". If they are stuck at 2 or 1 to go, double click on "Pinger Stats" and you should see that the tests are re-started and completed in very few seconds. The developers have worked hard to circumvent the numerous bugs in Mono 4 (especially. but not only, in WinForms) but some intrinsic bugs are impossible to bypass completely. For this reason, the developers have planned a massive migration to GTK+ (especially for the UI) for Eddie "branch" 3, at least in GNU/Linux. Kind regards

Hello! In general that's correct, but remapping ports will make torrent clients unreachable because they announce to trackers and DHT their internal settings configured port (of course) while the VPN server will listen to a different port. So, in this particular case, remotely forwarded port and local port must have the same number. For people running a torrent client behind the VPN, a good solution against various menaces inferred in this thread would be changing the listening port at each session. It takes a few seconds in the account control panel in our web site, and no "ports history" is ever recorded. Obviously if your threat model involves only private copyright trolls and similarly deranged persons, that would be not even be necessary. Kind regards

Hello, yes, all the IP addresses will remain the same. Kind regards

Chuck Norris mode, I suppose. He can start an upgrade on Aug 12 and finish it on Aug 6 that same year As you can see, our datacenters technical requirements are quite high. Kind regards

Hello! Starting from Friday August 12th 2016 @ 23:00h CEST until Saturday August 6th 2016 @ 03:00h CEST, the Netherlands datacenter technicians will re-locate fifteen servers to a new rack. Expected downtime: 4 hours. This will allow to add AMS-IX direct connectivity to all of the aforementioned servers. After the re-location, therefore, we will have 20 servers in the Netherlands with direct AMS-IX connectivity, The involved servers are: Alrai Ancha Caph Garnet Gienah Jabbah Kocab Maasym Mirach Miram Muscida Pleione Rukbat Sheliak Subra Kind regards

On the contrary, it has been resolved, anyway it has always been a non-real problem. If you did not upgrade to Eddie 2.11.x beta just allow the IP addresses required by Bonjour in Eddie "Network Lock" window : 239.255.255.250 224.0.0.251 Not needed on Eddie 2.11.x that allows them by default if "Allow LAN" is ticked Kind regards

Yes, always try out the newest version. If it doesn't work as intended, apply the fix. If it still does not work for you, downgrade to 9.9. If you're already using 9.9, consider doing nothing at all. We remind the casual readers that versions 9.9.2 and older are in many cases unusable in Windows 10. Kind regards I agree with the "older", but! One specific version, 9.9.2_3, works as intended. Yes, we consider 9.9.2_3 newer than 9.9.2. Kind regards