Staff

Hello, try to specify the full path to ca.crt in airvpn.conf file. Kind regards

Eddie 2.10.3 is unable to restore previous DNS settings if one or both DNS are previously omitted in the network interface and some other concurring circumstance is satisfied. Upgrade to 2.11.3 beta where this bug has been fixed. Kind regards

Hello! It looks like a matter related to sockets. . Also consider DNS caching by Firefox. The browser (but this behavior might change on different Operating Systems) might still be using some "old" socket, when your system had a different default gateway, a different routing table, different DNS settings and even an additional network interface When you restart the browser you get rid of all of the above. The behavior you describe has been successfully reproduced on various GNU/Linux systems (for example Debian 7 and 8) and is considered perfectly normal. Kind regards

We were talking about Windows. There is a specific bug (or a series of bugs) in OS X which makes things more confused. Try this, it's worth a test: http://osxdaily.com/2015/10/16/fix-wi-fi-problems-mac-os-x-el-capitan/ The post for Windows is useless for you, anyway here it is for the Windows readers: https://airvpn.org/topic/17037-cannot-log-on-to-any-servers/?do=findComment&comment=38862 Give us a way to reproduce this behavior first. Until then, we must assume it's not an Eddie bug. This does not mean that Eddie is not bugged, just like any software. Have a look at the changelog to see the amount of bugs which have been fixed and surely more bugs will be discovered. But a bug is considered real only when it is reproducible. Mono is bugged as well, so this pragmatic but scientific approach is strictly necessary, otherwise we would be hunting ghosts and talking about the sex of angels, with effects that would impair or even stop Eddie development. King regards

@mrburns Yes, purge all the packages from old Mono and install Mono 4. It is useless now to keep anything related to Mono versions older than 4, and maybe it could also pose issues. Kind regards

Hello, the logs are not satisfactory and suffer the identical previous problem we warned you about. Please shut down Eddie, re-run it, connect to ONE server. Just after the connection has been established re-take and re-post the logs. Kind regards

If and only if it's your router to run OpenVPN and connect to the service, you need to forward a port on your router too, but on tun interface (the virtual network interface used by OpenVPN). If you forward the port from the control panel, the router will forward them on the WAN interface, which would be useless (on the WAN interface packets are still encrypted) and would even expose your system to correlation attacks. Do the correct port forwarding (after of course you have forwarded the port on your account port control panel in our web site) with iptables - follow the guide in our How-To section: https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables/ Kind regards

You must shut down Eddie (on OS X) before putting an OS X machine to sleep. When you put the Mac to sleep you turn off the network card, but keeping the VPN gateway and routing table (no restore is possible). All connections are lost but at wake up OpenVPN still runs and the routing table and the default gateway are the old ones. Apparently this situation often causes OS X to become unable to perform a network reset. Maybe, just maybe, linked to some ancient bugs affecting OS X since a long ago and never fixed, for example: http://osxdaily.com/2015/10/16/fix-wi-fi-problems-mac-os-x-el-capitan/ You can find out that the problem is not caused by Eddie by reproducing it only with OpenVPN usage (of course, with a system that changes the default gateway, the routing table and the DNS) and then putting the OS X box abruptly to sleep when OpenVPN is still running and tunneling. Kind regards

Please note that there ARE problems with macOS beta, just it normally happens with any beta system pre-release. El Capitan, for example, was not even able to properly run OpenVPN and did not drive correctly utun at its first and second beta. It's useless now to discuss about it, normally tons of problems will be solved in the future beta versions, and even more in the final first stable release. Kind regards

Each node has a unique IP address in the virtual private network. See also "IP masquerading" and "Network Address Translation". Kind regards

@giganerd The output from ipleak helps a little in this case. From that output, note that the p2p IP address is correct and that there's no leak of any kind. So you can concentrate now on leaks caused by unexpected VPN disconnection which in turn generated the notice the user got. Network Lock might be disabled, or not working. @morjef7272 As giganerd noticed, your logs miss an essential part. Please re-send, but this time take them JUST AFTER a connection to a VPN server has been established. We want to see some additional things, including activation of Network Lock. Also, please specify whether you run some firewall (of any kind) that's a frontend to iptables. We ask because Network Lock uses iptables to prevent leaks. Network Lock is what you need to prevent leaks (which are the only possible cause of the problem you claimed), but you can't use Network Lock if you run some iptables frontend manipulating rules. Kind regards

Hello, just to make you notice that it's not true that there is "no real solution", and it's not true that the problem is common, since it affects about 1 Windows user out of 1000, which is excellent with a messed-up system like Windows (which can be messed-up simultaneously by Microsoft. by the machine manufacturer, and by the user himself/herself). Route checking is an additional feature (which can be de-activated) that warns you when the traffic is not properly tunneled, so you should be grateful that a problem has been detected, for your own safety and security. It's true that there is not a unique solution for all the cases, simply because the problem can be caused by various reasons. Anyway we have a series of suggestions which solve the problem 9 times out of 10. The essential steps to problem solving in this case are accepting that the problem can be in your system and learning how to let support team and community help you. Kind regards

What's the hardware? I've been reading much (and much is old anyway) and it says that OpenVPN is signle threaded but possible to reach 1gbps with decent processor. But it doesn't say what decent is. Hello, it's very important (at least for our setup) that the processor supports AES-New Instructions. The performance boost per core is dramatic if compared to a processor not supporting AES-NI. This article below is very interesting to optimize VPN servers in an attempt to squeeze almost 1 Gbit/s from one core and it can be useful even for clients. On the server side the task becomes even more difficult with multiple clients, because it seems from our empirical experience that the needed processing power does not grow linearly with the amount of connected OpenVPN clients (it apparently varies with some faster-than-linear growth). At least, on the client side you can ignore this problem. https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux Kind regards

Ubuntu 16.04.1 is Xenial Xerus. Eddie 2.11 is compatible with Mono 4 and works perfectly on Ubuntu 16.04. See also https://airvpn.org/topic/18625-eddie-211beta-available/ Even Eddie 2.10 portable version worked perfectly on Ubuntu 16.04, for obvious reasons. Now you can have also the installing version (which depends on Mono 4 now, not on older Mono versions), which is a major step forward. Thread locked, for any issue please move to the aforementioned Eddie 2.11 topic. Kind regards

It's the same, please make sure to shut down Eddie properly. All the settings are written in AirVPN.xml, so if .NET or Mono do some caching you could prevent the proper writing of the settings (according to your description, maybe you don't shut down Eddie properly). If you lose your settings even if you shut Eddie down properly, then please feel free to describe the exact steps to reproduce the problem (because we can't reproduce it). Kind regards

You are running Eddie 2.10.3 while the thread was dedicated to 2.11.x, so your message has been split from the original topic. Before anything else please upgrade to Eddie 2.11.x beta. Thread locked. Kind regards

Hello, download our free and open source client software, enable Network Lock, connect to a VPN server and run your torrent client. To increase performance of a torrent client follow the dedicated guide, you can find it in the FAQ answers (it involves remote port forwarding). It will also let you seed properly, even initial seeding of course. Subject treated in hundreds of posts, topic locked. Kind regards

Eddie 2.10.3 is not compatible with Mono 4. Please use Eddie 2.11.x beta, which is. https://airvpn.org/topic/18625-eddie-211beta-available/ This has been treated in so many posts and threads: topic locked. Kind regards

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