Staff

Hello, unfortunately, when not even your local network devices are under your full control, troubleshooting becomes much harder. We could assume that this router you cite has no active QoS tools, but it's safer that you get informed. Both. The tun/tap adapter is the virtual network interface used by OpenVPN and is driven by the tun/tap driver. You should have version 9.21.2 if you run Eddie 2.11.x beta, check on the Eddie logs. The driver for your physical interface can kept up to date with the Windows tools or the manufacturer's ones. Side note: of course, you need to consider that each routable packet that passes through the virtual interface also passes through the physical interface (although it's encrypted in the physical interface). Therefore if you monitor the total traffic and bandwidth in the system by adding up traffic and bandwidth of both interfaces, generally you will get approximately the double traffic and bandwidth that physically is handled by the physical network interface. Kind regards

Thanks, investigation in progress in OS X. We count to have OpenVPN over Tor again working when we release the stable 2.11 version. Kind regards

UDP to port 443 can be a factor to consider. You would be surprised to see how many bugged routers can't handle high UDP flows and many routers are still sold with archaic firmwares. Some of them even crash with UDP. Make sure that the router firmware is up to date. Other options to consider are any QoS tool in your router or system, or any third-party network manager in Windows. Finally, you can't rule out some ISP "traffic management" which penalizes UDP upstream, downstream or both when some pattern is detected. EDIT: This is an issue we have seen not so rarely in Windows 8 and Windows 10 when a 9.21.x tun/tap driver is used in a system with an outdated driver of the physical network interface. So, on top of all the above, please make sure that your network card driver is up to date. Worth a check. Kind regards

Almost surely this is irrelevant. The arrogance and the willingness to jump to conclusions made the original poster "ridiculed" by so many users. A message like the one from the OP is usually written by lamers and trolls, which might or might not be noobs. Kind regards

Providing PPTP should be considered negatively at least when some security is required. About the VPN servers amount, it looks like we have more servers than ExpressVPN. In the machines amount, we only count real, physical machines with a dedicated line and port, or at least a dedicated line for each of our racks. We don't count VPS or IP addresses geo-located to some country but assigned to datacenters in a different country and similar "tricks". It also looks like we provide a greater variety of protocols and destination ports, with the options to tunnel OpenVPN in additional stunnel and SSH tunnels, but we might be wrong, and a wide array of ports and alternative, partially hidden entry-IP addresses. Kind regards

Ok this work, but when i reboot the dns changes back. Is there away to keep this on or do i have to input this everytime i turn on the computer? Hello! Try to take care of DNS push. The following method is perfect if your distribution can run resolvconf: https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/ If your system is "based" on systemd instead of initd, you could experience problems even with resolvconf and the OpeNVPN script, unfortunately. In this case please see here; https://wiki.archlinux.org/index.php/OpenVPN#DNS As an alternative to all of the above, try our free and open source client Eddie for GNU/Linux. It brutally takes total control of /etc/resolv.conf to try to accept DNS push under any Linux system. Test Eddie 2.11.3 beta. Eddie 2.11.4 beta will have some addition to DNS handling to cover some more special cases. Kind regards

Hello, it is indeed possible to make Network Lock working with AirVPN over Tor. It's currently not planned but it might be implemented in the future. Eddie already talks with Tor control to get the IP addresses of the Tor guards. This is necessary to set the proper routes and avoid the infinite route loop problem (so the user does not need any middle box). The circuit is fixed for the OpenVPN stream, so no additional problems should arise. Kind regards The main problem is getting to know the Tor guard IP address, which is known only AFTER the Tor circuit for OpenVPN has been established, therefore only after OpenVPN has connected to Tor. For this reason any Network Lock plan for OpenVPN over Tor has been momentarily canceled. Kind regards

What? Since when? Where is the documentation for this, please? Since the beginning of 2015, a year and a half ago, but it was unofficial and not documented, and OpenVPN daemons were not linked to any system (so any malfunction would have gone unnoticed). It is still not documented but you might have seen that this is now included in Eddie, so when Eddie 2.11 "stable" will be released we will modify the "specs" page and add the new connection modes to our early warning systems etc. Kind regards

@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