Staff

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

Unless the average British citizen uses electronic equipment from 20 years ago, side-channel attacks can succeed in some cases when the attacked equipment is 2-3 meters away from the attacking equipment. Good luck in bringing a van 2 meters away to every and each electronic equipment in UK houses. While it's true that some side-channel attacks techniques are covered by military secret, so we might be ignoring something essential here, it's questionable that such secrets will be made available to "civil" BBC vans. It is reasonable to assume that such an action would expose the secrets to the unavoidable leaks which would bring them into the public domain in a matter of hours. Kind regards

Our plans explicitly exclude any new server until September, except for emergency cases. As usual various countries, including Finland, will be re-considered every 3 months, or even more frequently, according to variations of user-base and connection preferences in available countries. In the latest plans VPN servers in Finland were explicitly excluded because we did not need them. Kind regards

Hello! As you can see here: . 2016.08.06 01:54:30 - OpenVPN > RESOLVE: Cannot resolve host address: localhost: nodename nor servname provided, or not known the problem is in your system. A system MUST be able to resolve name "localhost". You don't find this problem in Tunnelblick because it contacts OpenVPN management at 127.0.0.1, but Eddie approach is more correct. You might experience additional problems if you don't make your system capable to resolve localhost. In El Capitan the hosts file is /private/etc/hosts Quick guide to edit it: https://www.ihash.eu/2015/09/how-to-edit-hosts-file-in-mac-os-x-10-11-el-capitan/ 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 ones are in many cases unusable in Windows 10. Kind regards

They serve the purpose of AirVPN mission and meet our technical requirements. Kind regards

Is this a parody or some elaborated joke? It sounds hilarious, to say the least. And technically it is totally ineffective, irrelevant. Kind regards

Hello! Bonjour is now allowed with Network Lock. If any of the issues you cited were caused by Bonjour block, now they are fixed if "Allow private/LAN" is enabled (ticked). Upgrade to 2.11.3 beta and test. If the problem is not solved you can explicitly allow the IP addresses required by those protocols in "AirVPN" > "Preferences" > "Network Lock". Kind regards

FEDORA 24 "resolv.conf" DNS issue Hello, we're glad to inform you that the problem has been detected and looks specific to Mono but occurs only under Fedora. A fix has been found and is being implemented in the next build which will be released in the nearest future. We can close this argument and focus on other glitches or bugs, if any. Kind regards

I think because they've deleted that thread. Correct, it's "hidden", since Netflix access has been variable and now no more possible from our infrastructure. Kind regards

DNS settings of your interfaces are correct. Can we see the screenshot showing this leak? Kind regards