Staff

Hello! Which is not much: routing table and pf rules. When this happens just re-run Eddie and it will detect the previous crash and put everything back in order. This is of course not an excuse for the crashes, but we don't have reports about such crashes, so please post the complete crash dump when possible (and if available) or enable logging on file (in "Preferences" > "Logging") and send it to us after the crash. It could provide the developers with some useful clue. Eddie does not create or configure tun adapters. Normally you don't need to worry about them, since they are handled by Mac kernel, while OpenVPN (and not Eddie) configures them. Older Mac systems had various bugs about tun but after the implementation of utun the system issues have been progressively solved by Apple. Kind regards

Hello and thank you very much for having tested Eddie and for your suggestions! This feature was planned and now it works properly. Forget the old "com" application, try the new Eddie 1.0 RC1 RC2. Please see here: https://airvpn.org/topic/26549-eddie-android-edition You can define black and white lists of applications whose traffic must be included in or excluded from the VPN tunnel in "Settings" > "Application filters". This is caused by the elephantine dimensions of Mono. Eddie Android upper layer is written in C# so a hundred or more additional megabytes are required for Mono libraries etc. We might change this in the future (it was not an easy choice) and renounce to Mono pachyderm in some future, but not before we reach 1.0 stable version. We are aware that a difference in footprint of 120 MB is a problem in some mobile devices. Very true. However, while Eddie progresses toward integration with AirVPN and therefore making the usage of ovpn profiles not required, this point will be overcome and Eddie will be more comfortable than OpenVPN for Android (at least with AirVPN). Thanks, keep testing and don't miss the future RC2 which should be released soon! Kind regards

Hello! In OS X or macOS (and in any other Operating System) Eddie does not create or remove tun/tap adapters. The utun cards are handled by the operating system with its own kernel modules, while OpenVPN just brings a utun up or down and configures it with the proper settings. Can you please clarify? Also, the amount of utun cards has nothing to do with other cards, so we don't see how that could be linked to the other problem you mention, about which we would recommend that you check your system DNS and firewall settings. Kind regards

Hello! Nothing new, same situation since 2012 at least. From China you need "OpenVPN over SSL" to port 443 (you can configure it with a few clicks in Eddie) or connect over tls-crypt to entry-IP addresses 3 and 4 in TCP (preferably to port 443 to avoid some outbound port block which could be sometimes enforced), when you find a line that's blocking OpenVPN and UDP. Connecting with "tls-crypt" saves you the pain to configure "OpenVPN over SSL" in Android. Currently about 80 Air VPN servers support tls-crypt The fact that you could connect successfully in UDP is a lucky event according to the reports we have. In most cases that's not possible at all from residential, fixed lines, and from mobile lines. Restrictions anyway seem less stringent in tourist and business towns. This looks like a bug, it's under investigation, thanks. Thank you for the report. Kind regards

Hello! You're wrong in this case. The screenshots show NO WebRTC leaks. Note how the addresses showed in the "WebRTC" section of ipleak.net web site are your private, non "publicly routable" addresses, as clearly specified by the web site itself. A note for the readers: WebRTC functions (and any similar function) can be prevented by Eddie only through firewall rules so make sure to enable Network Lock in Eddie. Some more thoughts about WebRTC can be found here: https://www.clodo.it/blog/an-alternative-approach-to-so-called-webrtc-leaks Since you have, apparently, pure IPv6 connectivity, please keep testing Eddie beta version and make sure that no IPv6 public address of yours appears in ipleak.net when Network Lock is enabled. To avoid confusion in this case to the casual readers we have renamed the thread with [FUD] prefix. Kind regards

Hello! Yes, with "OpenVPN over Tor" that's expected, for the reasons mentioned in our previous post in this thread (to put it in simpler terms, "that's how routing works"), when you generate traffic from an application (different than OpenVPN) configured to connect to Tor, while traffic of all applications NOT configured to connect to Tor will be tunneled over OpenVPN over Tor. For an additional test to check whether your configuration is working properly, connect OpenVPN over Tor with Eddie, run a browser NOT configured to connect to Tor and browse ipleak.net . Verify whether the IP address is the exit-IP address of the AirVPN server your device is connected to. Kind regards

Hello! Thank you for your choice and for the trust you put in us. That warning is correct and can be extended to any node your traffic passes through. Each node has the potential to see your traffic content. In your case, you move your trust from your ISP and anybody wiretapping your ISP lines, to us and anybody wiretapping the datacenter lines. You get protection from your ISP and other entities willing to spy on you between your node, your ISP and any other node between you and our servers. Even if you trust us blindly, you can't be sure that someone else is monitoring our servers. So, in every situation for which you just can't afford to trust us or the datacenter, you MUST use end-to-end encryption. In this way our servers and any hostile entity monitoring the servers line can't see your traffic content. The huge difference is that the protection against your ISP is more valuable than anything else, because you get a first, strong protection layer against local entities which have higher likelihood to have you as a target (for marketing reasons or more sinister reasons). And that's not all, because you can add a second protection layer which will protect you against us and any malicious entity INSIDE the datacenter our servers are located: use end-to-end encryption, and add Tor over the OpenVPN connection, according to your threat model. Another important factor is the protection you get against the final destination of your communications: when they get out of the server, your packets do not contain your "real" IP address. There are a variety of common situations for which you want to hide your real IP address to the final destination of your communications. A more extensive analysis of this issue can be found in the post linked below. Please take some minutes to read it, it's important. In this way you can make the best decision according to the evaluation of the power of your adversary, in other words according to a reasonable threat model that only you can estimate. When you need to exchange extremely sensitive data, for example, simply using the VPN over Tor and using end-to-end encryption will make a huge difference by strengthening remarkably the anonymity layer. https://airvpn.org/topic/54-using-airvpn-over-tor/?do=findComment&comment=1745 Last but not least, remember that our service protects your data in transit, and NOT your computer, so the essential pre-requisite of everything is that your device is not compromised (by spyware or anything malicious). Some more food for mind can be found here: https://airvpn.org/topic/26206-rebuttal-of-article-dont-use-vpn-services/ Finally, an important remark about iOS. Many Apple services such as Push Notifications and FaceTime are never routed through the VPN tunnel, as per Apple policy. We have come to know this from the openvpn-connect FAQ here: https://docs.openvpn.net/connecting/connecting-to-access-server-with-apple-ios/faq-regarding-openvpn-connect-ios To stay on the safe side, when security and privacy are a priority, you should consider an iOS device a nice toy which is not suitable for certain purposes (check again your threat model). Kind regards

Been a week now. Is someone going to tell us if it was intentional or by accident? Hello! It was intentional, according to the consideration that it is more appropriate and fair to keep the original signature of the packaged binaries not programmed by Air, but as you correctly remarked this failure of communication is our failure and we will improve and learn from this mistake. Kind regards

And just to be sure: The exit-IP address is the one we see when we look at the list of servers and their addresses which are available to us, right? Hello! Nope, that's the entry-IP address, if what you write is understood correctly. For example, let's take server Chamaeleon. It has the fully qualified name chamaeleon.airservers.org which resolves into the entry-IP address of Chamaeleon. $ dig chamaeleon.airservers.org +short 199.249.230.41 See also here for further information about that: https://airvpn.org/topic/14378-how-can-i-get-vpn-servers-entry-ip-addresses Exit-IP address of Chamaeleon is different. Yes, that's the exit-IP address. Kind regards

Hello! Vulnerability affecting Eddie for Windows installing packages downloaded earlier than Tue May 15 12:51:22 UTC 2018 in already compromised systems. Any other package type for Windows and any package type for any Operating System is not and has never been affected. Eddie Windows NSIS installers have three vulnerabilities described in ​NSIS bug 1125. The most serious of these issues (#1) allows running unsolicited code and an escalation of privilege attack using DLL Search Order Hijacking (​CAPEC-471) as Eddie Windows installers are generally executed with Admin privileges. What NSIS/Windows does is actually prefer loading DLLs in the current directory, which in case of the Downloads folder is writable by the user. Thus the vulnerability is trivial to exploit, but only if the attacker has already managed to get a malicious DLL into user's Downloads folder https://sourceforge.net/p/nsis/bugs/1125/ This issue was brought to our attention by Kushal Arvind Shah of Fortinet's FortiGuard Labs on May 14, 2018 and fixed by us Tue May 15 12:51:22 UTC 2018 in any Eddie 2.13.* Windows installer releases and above. Download of older versions has been disabled. Side note: any Eddie version older than 2.13.6 for any system has now been removed from the download list. Such versions are obsolete and the removal complies to security considerations as well as compatibility considerations with the developments of the respective Operating Systems.

Just for additional (and probably useful) information, entry and exit-IP addresses in our service are different. Even nowadays, that's not true in many VPN services. Keeping different entry and exit-IP addresses prevents various correlation attacks which can even lead to the discovery of your real IP address, even when OpenVPN works perfectly (it's a method which exploits just how the Internet routing works). For the casual reader, a clearer explanation. When you connect to an Air VPN server, you connect to some IP address (we call it the "entry-IP address" of that server). However, your packets reach the Internet from a different IP address (we call it "exit-IP address" of that VPN server). The main reasons, though, for which AirVPN seems more expensive than other services in some cases are: 1) the guarantee of no overselling (unique feature as far as we know) - this is terribly expensive 2) the lack of fake IP addresses. Some big VPN services advertise something like 4000 servers but when you dig deeper you just see that each set of dozens or even hundreds IP addresses end up to the same server 3) the lack of virtual servers, we only own or rent physical, bare metal servers with certain hardware requirements That said, nothing is immutable and two year plans as well as rates review are not in principle impossible, but we must keep everything compatible with our mission, in other words we are not going to cut rates by overselling or through fake machines, obviously. Kind regards

Hello! That's not the correct way to do it, especially with Facebook! Probably you did not get the full implications of what we wrote earlier. Anyway in this usage example Facebook may correlate your proxy IP address with your VPN IP address (through one of its infinite spy plug-ins or with the aid of a third-party web site you open with another browser because you would like to appear there with your VPN IP address or in even other ways), and not with your "real" IP address. Once again your purpose is defeated. Maybe these "VPN browser extensiosn" are just bloatware giving a false sense of trust, which is dangerous. Even the definition is a blatant lie ("VPN"??? they have nothing to do with VPN). Privacy enhancing methods are not always "practical", in spite of our efforts. We can't protect you against yourself and your bad habits, but we can try to raise your awareness about the risks you are not aware of. Kind regards

Can you explain why this is important? The entry IP appears to be fixed, either 1 above or 1 below the exit IP depending on if you use the standard entry IP or the alternative. Any adversary would know the two possible entry IP's from the exit IP. Hello! It's of vital importance because it prevents specific correlation attacks aimed to cause your system to exchange data outside the VPN tunnel when you use remote port forwarding. It's trivial to successfully perform such attacks when the entry and the exit IP addresses match. Anybody can therefore discover your "real" IP address (and this is what normally happens in many VPN services which provide remote port forwarding, we would not even define them as "competitors" anyway). Additionally your assumption may be correct or not but is irrelevant. Correlations in low latency networks become more difficult when exit and entry-IP addresses do not match, regardless of their subnet. Kind regards

Hello! That's just fine. When OpenVPN is connected to Tor, and you use another application which is configured to connect to Tor, that application traffic will be tunneled over Tor only. You can see the reason by looking at the routing table and the gateways of your system. On a qualitative level, let's say that an application configured to connect to Tor proxy locally will connect to Tor proxy locally, it has no way to route the traffic on the tun interface to reach the VPN gateway which can be reached only over OpenVPN over Tor (OpenVPN connects to Tor proxy locally as well). In https://airvpn.org/tor you can see the above depicted in the first picture. If you need Tor over OpenVPN, connect OpenVPN directly to a VPN server, then use Tor. All the applications configured to connect to Tor will have their traffic tunneled over Tor over OpenVPN. Kind regards

Hello! The browser extensions you mention configure your browser to tunnel its traffic, and only its own, over some SOCKS or HTTPS proxy. Normally it has nothing to do with entering a Virtual Private Network and should not be considered a reliable method to build an anonymity layer, not even a weak one, because all the other traffic (system traffic, other applications traffic, traffic generated by plug-ins too in some cases) will not be tunneled. On top of the above some technical challenges and concerns about DNS pre-fetching and more in general about the fact that DNS queries will not be tunneled anyway in some systems (Windows) under not uncommon circumstances must be taken into account. So the whole matter seems outside AirVPN scope, as AirVPN service is meant primarily as a privacy enhancing service through an anonymity layer which aims to not let any single packet go out to the Internet with your "real" IP address AND to send to the Internet packets with an IP address that's even different than the IP address of the VPN server you connect to (a very important feature that is often overlooked and which is not offered by many VPNs, and that anyway can't be offered by a proxy). It might be a service for other purposes, but it does not seem aimed to create any anonymity layer of any kind and/or to the purpose AirVPN is meant for. Kind regards

Hello! You are capped through traffic shaping. either enforced by yourself (check any filtering tool on your router and system) or more likely by your ISP. Note how TCP is faster than UDP. This makes no sense in an agnostic network because OpenVPN is much faster in UDP, so it's a strong clue hinting to traffic shaping. Test an "OpenVPN over SSL" connection to port 443 (a good approximation of HTTPS so to say), or a tls-crypt featured connection to entry-IP 3 or 4 to see whether they can mitigate or bypass the throttling techniques. Also consider to change ISP if possibile. You can change connection mode in Eddie Preferences > Protocols. Remember to click "Save" and restart a connection each time you change setting to apply the change onto OpenVPN. Kind regards

Hello! An additional information for those who need larger buffers when using Eddie: you can enter custom directives rcvbuf and sndbuf in "Preferences" > "OVPN Directives" custom directives field. Click "Save" after you have entered them and restart a connection to apply the change onto OpenVPN. The syntax is: rcvbuf receive_buffer_size sndbf send_buffer_size where receive_buffer_size and send_buffer_size are in bytes. Example: rcvbuf 1048576 will tell OpenVPN to create a 1 MB (1048575 bytes) receive socket buffer. Kind regards

Hello! We would like to investigate, your specific case is interesting. Your node is behind DSLite stack, with only IPv6 connection (IPv4 is encapsulated in IPv6), but you appear to have only IPv4 in the tunnel. Can you post a system report taken just after the problem has occurred to check Eddie settings (in particular about how it must handle IPv6)? "Logs" > life belt icon > copy all > paste into your message. Kind regards

Hello! Confirmed and reproduced in RC1 and Oreo. We are currently testing internally a fixed version. If everything goes well you will see RC2 quite soon. Kind regards

Hello! Yes, that's the option you look for. In the option comment you should be able to read: "Pause VPN when the screen is off. When this option is enabled, no traffic will be generated by the VPN when the screen is off. This also saves battery when the screen is off." Kind regards

Hello and thank you for your report! Can you please make sure that the option "Show notification" is ON? If it's turned off, Android can put the application to sleep according to its own resources management, causing VPN disconnection (Eddie displays a warning about that anyway). Please feel free to keep us posted. Kind regards

Hello! It surely can lower you anonymity layer and even for other, somehow more serious reasons. That's why we don't log the port history and you can delete a forwarded port anytime. Also, it is very important that you keep Network Lock enabled when you remotely forward port. Really important. Not that someone needs to worry about copyright trolls and similar bums, but if you need to listen to a port for some very sensitive activity in some hostile to human rights environment, keeping Network Lock enabled and deleting the port soon after the usage may help you sleep slightly more comfortably. Note that for "deleting the port" we mean that you delete it from your account panel as well as you change it from the configuration of your listening service(s). Kind regards

Hello! Of course. Documentation and instructions will be published before the release of the stable version. Kind regards

Hello! A 100% safe traffic leak prevention outside the VPN tunnel (we guess you mean that with "kill switch", is this right?) is impossible on a machine you don't control as root (administrator) but Eddie will perform a best effort to prevent leaks just like any other OpenVPN based application on Android. Please make sure that "TUN persist" and "Pause VPN ..." options are both active for this purpose. About the event you report, can you please add some more details? When you switched from WiFi to LTE, did OpenVPN disconnect and then never re-connected until you restarted Eddie? Can you reproduce the issue and post the full OpenVPN log taken after the problem has occurred? Kind regards

Hello! We're very glad to inform you that Eddie 1.0 Release Candidate 1 has just been released. RC1 has been linked against mbedTLS (formerly known as "PolarSSL") instead of OpenSSL. This decision has been taken because, according to our tests, performance with OpenSSL and mbedTLS is identical, while mbedTLS ensures a longer battery life under intensive usage: approximately a 10% improvement. This change also makes the package lighter. We warmly invite you to test as much as you can and report any glitch and bug you should find. We would like to thank all the beta testers so far: thanks to them the development cycle has been very fast and we are so near to release a stable version. Thank you! As usual Eddie is free and open source software released under GPLv3. You can participate to the beta testing by joining the beta community in the Google Play Store here https://play.google.com/apps/testing/org.airvpn.eddie Alternatively, if you don't want to access (or you have no access to) the Google Play Store, the apk can be downloaded from our Eddie web site here: https://eddie.website/repository/eddie/android/1.0rc1/org.airvpn.eddie.apk Kind regards and datalove AirVPN Staff ChangeLog.txt ChangeLog-1.0RC1.txt