Staff

Hello! Since Eddie 2.5beta this option is implemented and its name is "Network Lock". It is implemented with plug-ins. In Linux, the available plug-in needs iptables, so all Linux systems which have iptables can use it. Eddie 2.6 is a stable version (no more beta) but the "Network Lock" option is still marked as "experimental", however no problems at all have been detected so far with iptables plug-in. See also: https://airvpn.org/topic/12175-network-lock As usual, we recommend to follow "News and announcements" forum to remain up-to-date with constant AirVPN development in all fields. https://airvpn.org/forum/9-news-and-announcement Updates are also published through "AirVPN" accounts in Twitter and Facebook. Kind regards

Hello, yes, if we had a house in the USA that would be a trivial solution, with a good residential line with high bandwidth. Kind regards

Hello, Eddie doesn't do anything with the tun/tap driver, it is "handled" indirectly by OpenVPN (in the sense that when OpenVPN brings up/accesses the tun interface, the OS relies on the tun/tap driver). We'll check your report with the programmers. Kind regards

Hello! Problem identified, a fix is ongoing. Next client release 2.7 will include the fix. Kind regards

Hello! Can you post the logs pertaining to the problem? In Windows, if you run Eddie, please click "Logs" tab, click "Copy to clipboard" icon and paste into your message. Kind regards

Hello, we do not detect this behavior. Eddie turns off the firewall only if it had to be activated by Eddie itself. Kind regards

Hello! The route check fails. Please try to un-tick "Check if the tunnel effectively works" in "AirVPN" -> "Preferences" -> "Advanced". Connect again and check whether the tunnel works manually by browsing to https://airvpn.org and checking the color of the central bottom box (it is green and displaying "Connected!" if traffic is tunneled properly). If everything is fine, then you might like to enable "Network Lock", because the initial route checking will no more be performed. Kind regards

Hello! 1. Please upgrade to Eddie 2.6. The issue should have been fixed in it. 2. Please upgrade to Eddie 2.6. The issue should have been fixed in it. 3. That's correct and intentional. 4. You need to enter administrator password anyway. A glitch on connection at program startup has been fixed in Eddie 2.6, please upgrade. 5. Ok. The route checking needs some investigation under Windows. 6. Please upgrade to Eddie 2.6. The issue should have been fixed in it. Please upgrade to Eddie 2.6. This option has been implemented in it. Yes, as you are surealy aware, you're running a beta version. Please upgrade to Eddie 2.6, which is the first stable release BUT implements experimental plug-ins (all the Network Lock plug-ins are experimental). Additionally, Eddie is being actively developed. Kind regards

Hello, it is not simple to implement it in our service, there are serious issues. Anyway our reports from China are very good, there is no need at the moment to add anything else, especially something so problematic like the proposed patch. Kind regards

@Sinta First of all please check the firewall in your router as well. Please try different ports, just in case your ISP hijacks UDP packets to port 53 (Vodafone does that, to force their DNS usage). Also try TCP, in case your ISP blocked outgoing UDP packets to certain ports. Kind regards

Hello! It is not possible to go over 3600 seconds because our servers WANT to re-negotiate TLS keys at least every hour. This is intentional because we wish to provide Perfect Forward Secrecy. We wouldn't be worried about entropy limitations for re-keying with your Broadcom processor, why are you? Are we missing something? Kind regards

Hello! Very interesting. It comes out that "the personal iOS hotspot feature, as for the USB/bluetooth tethering and MyWi, binds the traffic on a the 3G interface. OpenVPN changes the routing and uses the PPP interface, so the packets coming from the shared clients are bound to the 3G but the system route is going to the PPP interface, so it doesn't work." (by the author of GuizmoVPN app: http://www.guizmovpn.com/index.php?option=com_agora&task=topic&id=119&p=1&Itemid=15#p438 ). Kind regards

Hello! Confirmed, Eddie seems to be working very nicely in Yosemite preview. This is a good sign: probably it will work as it is in Yosemite official release. Eddie core 2.6 is no more beta, it is a stable release, BUT Network Lock plug-ins are experimental. Kind regards

Hello! We cut the ads. Some possible attempts you can try are explained in reply to your ticket.Actually it looks like you could manage to bypass incoming traffic shaping. Maybe outgoing traffic different than a whitelist of protocols (we mean protocols at application layer) is shaped unconditionally by your ISP. Kind regards

Hi, yes, we'll consider it. Kind regards

Hi, this is a an important question. We have recorded a dramatic increase of clients requiring connections to NL servers in the past weeks and months. With the increase of single connected clients (consider that since April a user can connect simultaneously three clients and also consider that Air user base has grown up considerably during this year), we must take into account different variables to a server load in addition to available bandwidth. CPUs of our servers not only must handle TLS auth and OpenVPN AES-256 encryption/decryption, but also SSH and OpenSSL additional tunnels. There is, so far, no scientific study which determines how the CPU load increases (under the same provided bandwidth) with the increase of connected clients in an OpenVPN server, but empirically it might be not linear (example: 50 clients requiring 1 Mbit/s each stress CPU more than one client requiring 50 Mbit/s does). So, we could have a server that has a line and a port of 1 Gbit/s, but whose CPU gets at capacity before that limit (for example already at 650 Mbit/s). Therefore, in order to respect our commitment to always provide at least 4 Mbit/s per client in at least one server in the world, we add servers before this limit is reached. In the particular case of the Netherlands, we have decided to go beyond our warrant, because customers clearly appear to be very interested in this country. With the current configuration and considering the average numbers of clients connected to Netherlands servers with an excess prudential margin of 20%, we are now able to provide more than 4 Mbit/s per client in the Netherlands alone, even keeping into account potential aforementioned overhead. In the "Top 10 Users Speed", right now, we can see that the topmost 4 clients are all in the Netherlands, ranging from 65 Mbit/s to 40 Mbit/s each. Kind regards

If the suggestion to resolve this issue is to use an additional paid service then that is not a viable solution for me. If unblock-us can continue to bypass Hulu's geolocation restrictions then why can't AirVPN? I don't know about other members but I don't want to be (and can't afford to be) paying for an additional proxy service just so I can watch Hulu. When this has happened periodically in the past it has always been resolved quickly. It seems like this time there is no desire to fix the issue which is disappointing to say the least. "Not in the near future" isn't very encouraging. Please let us know what is the plan and timeline to resolve the issue? This must be affecting tonnes of AirVPN users right now. Hello, unblock-us uses a server whose IP address is still not blocked by Hulu. It might get blocked tomorrow, in a hour, or in 10 years, who knows. Our service uses micro-routing as an experimental feature, we are focused on VPN services aimed to privacy, anonymity and data protection, while unblock is exclusively concentrated on DNS and reverse-proxy services to bypass geo-restrictions (so such a service can't work if the IP check is implemented also at streaming level: your real IP address is visible and the stream is sent to it - unless you're connected to a VPN). You just can not compare such services. Our service is more complete in the sense that it can include services such as unblock-us and preserve privacy and anonymity at the same time, but in any case it needs an IP address that's not blocked by Hulu and at the moment we do not have such IP address. As soon as and if we have a solution we will be able to publish an ETA for such solution implementation. Kind regards

Hello, our OpenVPN Data Channel cipher is AES-256-CBC. You're getting the maximum AES-256 throughput that can be sustained by your router CPU (assuming that OpenVPN runs on Shibby Tomato). AES-256 is a high grade encryption that's computationally heavy for a consumers' router CPU. In other services, if no encryption or weak encryption is used in the OpenVPN Data Channel, throughput will be obviously much higher, at the price of significantly lower security. You can anyway bypass the bottleneck by connecting directly your computers (up to three simultaneously) or using a more powerful routing box (see pfSense for example). Kind regard

Hello! We're very glad to inform you that five new 1 Gbit/s servers located in the Netherlands are available: Ceres, Julliet, Pallas, Riguel and Sedna. The AirVPN client will show automatically the new servers, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Ceres, Julliet, Pallas, Riguel and Sedna support OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello, route checking fails, please try to disable it. Un-tick "Check if the tunnel effectively works" in "AirVPN" -> "Preferences" -> "Advanced". After that try again a connection to a VPN server, browse to airvpn.org and verify whether the central bottom box is green or red. If it's green, everything is fine. Since the route checking is somehow a security check, if you need to keep it disabled for this problem we would suggest that you activate "Network Lock" (available only on Eddie 2.5 or higher). Kind regards

Hello! Clearly some system of our customers is infected. Kind regards

Hello! The TLS Cipher is wrong. Try with "None". If it fails, try with "TLS-DHE-RSA-WITH-AES-128-CBC-SHA". Both are very wrong but for some DD-WRT glitch, on newer builds either the first or the second work, while all the other ones (wrong as well) fail. Kind regards

@dd79 thank you very much!

Hello, it seems that some certificate or key has not been pasted correctly or that the cipher you selected is wrong. A screenshot of the DD-WRT OpenVPN client configuration page may help. Kind regards

Hello! Your method is perfectly fine. In Eddie Network Lock has not been implemented in this way for some potential problems in specific configurations, we needed a method that must be as generic as possible and applicable to a wide amount of systems. Additionally, Eddie performs a lot of tests for servers ratings, but the route command execution can be extremely slow in Windows: keeping the rating system with Network Lock would have needed dozens and dozens of route commands with huge delays. Kind regards