Staff

Hello! It's a DNS issue on imdb.com side. See here: https://mxtoolbox.com/domain/imdb.com/ Of the three red errors reported, "Primary Name Server Not Listed At Parent" is the one causing the intermittent problems you mention. Kind regards

Hello! White and black list are intended in the most classical way. If you define a black list: all traffic will go inside tunnel except the traffic of the apps in the black list If you define a white list: only traffic of the apps included the white list will go inside the tunnel. Important: please do not forget to send us a postcard from Raccoon City. Kind regards

This is impossible: even if the server was compromised (and it is not, but let's imagine this scenario) your credit card details could NOT be seen on the server itself or ANYWHERE ELSE between your node and the final recipient of the communications, because the credit card transaction is encrypted end-to-end. This is the foundation that makes financial transactions possible on the Internet (or on any digital network you can imagine). In other words, it's TOTALLY IRRELEVANT in this incident whether the server is "compromised" or not. And frankly, if you did not know this trivial fact, why did you suspect our VPN server and not any other node between you and the final processor of your card? Therefore, ruling out the trivial case that your card info has been taken physically by someone who could physically see your card front and rear and knows your birth date etc (a fact which is still the source of a large percentage of cc frauds around the world), your description of events can be explained ONLY by assuming that one of the ends is compromised, because only those ends can see the data in clear text, and precisely: 1) your computer 2) the payment processor of the train company (or the train company payment system itself if they do not use external payment processors) Sorry to underline again this but you are in AirVPN forums: of all the possible parties, you ended up suspecting the only one which mathematically can NOT be the culprit. Kind regards

Like the previous if to-be-disregarded workaround, this one delivers as well. Excellent. Still, it kind of defeats the Allow-Lan/Private tick box’s purpose (ever since vs 2.13.6 no less). Worse, going by your edit above, it effectively disables the network lock for all incoming connections. Hello! It's your choice. In this way you are anyway protected because any listening service can't answer to the Internet, so it makes no difference under this respect. The big difference is that your system will answer to your local devices. That's what you asked for! Can you trust them? Use this option only if you are the owner and administrator of such devices and you are sure they can't be exploited to launch attacks to the other devices in your local network. Anyway it's the very same hazard you have without VPN, nothing more nothing less, so in this specific case we can't see the point... Kind regards

Hello! We report the resolution of the problem according to your ticket to inform the readers. Problem has been solved by upgrading to latest Eddie version. Kind regards

Hello! Please try the following settings: set Preferences > Network Lock > Incoming to Allow (but keep Outgoing to Block)enter the following addresses in the box Allowed addresses: 239.0.0.0/8 224.0.0.0/22 click Save disable and enable "Network Lock" Kind regards

Hello! Thank you for your suggestion. Yes, we will. Planned for version 2.0. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s servers located in Vancouver (Canada) is available: Pisces. The AirVPN client will show automatically this new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other "second generation" Air server, Pisces supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.2 and tls-crypt. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the server status a usual in our real time servers monitor: https://airvpn.org/servers/Pisces Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! They are not able (at the moment) to block AirVPN. They try to do it with a different method which is specific against Eddie and not against OpenVPN. To bypass this block you need support from our support team (or just don't use Eddie). Bypassing the block with Eddie can take just a few seconds. Note: we will split this thread because your and our last messages are off-topic. Kind regards

Apple forbids and fights free and open source software on its store and at the moment we have no plans to release closed source software. On top of that Apple underlines that any Apple application traffic can bypass any VPN anytime. Before entering development in such a locked, dangerous and somehow contrary to our mission environment we need to consider every aspect carefully. Kind regards

Hello! We're glad to inform you that we plan to keep serving VPN even from the Vancouver area. We are testing a new provider to check if it fits our requirements since the current one does not. Kind regards

Hello! Yes, we're glad to inform you that this is planned for version 2. You will see something new during October. Kind regards

Thank you! We are proud to see a confirmation to our tests. At the moment we see that Eddie, on equal terms, is much more battery conscious than OVPN for Android and openvpn-connect. You can expect a 15-20% longer battery life on the same footing. Kind regards

Please contact the respective VPN services customer care. Eddie is based on OpenVPN 3 and OpenVPN 3 is configured by the profiles provided by each VPN service. It's not up to us to provide support for what you mention. Kind regards

Hello! A simpler setup with the same anti-blocking effectiveness can be achieved with the following connection mode which does not require any additional SSL tunnel: - entry-IP address 3 - protocol TCP - port 443 In the Configuration Generator, please tick "Advanced Mode" to display all the available connection modes. If you run Eddie on a desktop computer, connection modes are available in "Preferences" > "Protocols" and they are selectable after you untick "Automatic". Kind regards

Hello! We're glad to inform you that Eddie can work with additional SSL tunnels as usual but you don't need them with tls-crypt. tls-crypt already encrypts the whole OpenVPN Control Channel. Combining tls-crypt with TCP, you will have the same result without the additional burden of the SSL tunnel and in some cases you will not even need TCP (making OpenVPN more efficient). This has been tested from China by a dozen of users living there (we thank them for their thorough tests and reports) and tls-crypt to port 443 in TCP is able to bypass blocks always. That said, failure to connect to an established SSL tunnel to our VPN servers may be caused by some misconfiguration that deserves to be investigated (a trivial example, you generated an UDP config), but in any case you might like to get rid of the additional SSL tunnel which only adds burden to your Android device without adding any significant security layer. Remember that any obfuscation is weaker than real encryption of the whole Control Channel. We have chosen a stronger method than simple obfuscation and that's the reason for which our VPN service works where most other competitor VPNs fail. A special note on the remark you made: "VPN immediately fails upon connecting to my SSL tunnel profile, and then proceeds to leak all of my traffic anyway instead of warning me and keeping the network locked.". First of all, you ARE notified, because Eddie sends a notification of "Disconnected". Second, if no VPN tunnel has ever been established there's no way to pause or lock the VPN or the network (at least on an un-rooted device). This is an obvious limitation on ALL systems in which the app does not have root access and you will find the exact same limitation on any other OpenVPN based app for Android. The huge difference between Eddie and, say, OpenVPN for Android you mention, is that Eddie can prevent leaks in many situations under which OVPN for Android fails to do so. For example, test Eddie under the condition of an ongoing VPN failure for KEEPALIVE_TIMEOUT or TCP EOF. You can simulate this condition (which will occur when communications to the VPN fail definitively for any reason, a common situation in mobility) by revoking your client certificate/key pair and then forcing a disconnection from your account "Client Area". You will see that Eddie will properly lock, and prevent leaks, while OVPN for Android will not. Kind regards

Hello! That was a painful but due choice. In Android 5.0.1 known bugs in Android ConnectivityManager may affect network pause/resume/failover. Because of such bugs, we would have been unable to release an application capable of robust leaks prevention in various circumstances and we might have met additional problems. Samsung phones with Android versions older than 5.1 also suffer of additional bugs affecting VPN operations and VPN DNS. Kind regards

Hello! We are very glad to inform you that Eddie 1.0 for Android systems has been released. Eddie Android edition is a free and open source OpenVPN 3 GUI released under GPLv3. Source code is available here: https://gitlab.com/AirVPN/EddieAndroid Main features: Free and open source application based on OpenVPN 3Only official application by AirVPNRobust, best effort prevention of traffic leaks outside the VPN tunnelBattery-conscious applicationLow RAM footprintOption to start and connect the application at device bootOption to define which apps must have traffic inside or outside the VPN tunnel through white and black listOpenVPN linked against mbedTLS libraryAndroid 5.1 or higher requiredfully localized (current available languages: English, French, Italian, Spanish, Turkish)The traffic leak prevention has proved to be stronger than the one implemented in OVPN for Android. A thorough OpenVPN error detection allows Eddie to "lock" the network in case of unrecoverable disconnection (for example when communications to the VPN server get broken). Direct link to the Google Play Store: https://play.google.com/store/apps/details?id=org.airvpn.eddie Direct link to download Eddie Android edition from our Eddie web site: https://eddie.website/repository/eddie/android/1.0/org.airvpn.eddie.apk A quick tutorial is available here: https://airvpn.org/topic/29660-using-airvpn-with-eddie-client-for-android/ The APK will soon be available in F-Droid repository too. This is a starting point: development of a new version which includes stricter AirVPN integration is already ongoing and we are confident to provide you with updates in a very near future. Kind regards and datalove AirVPN Staff

Hello! First of all, it should not crash: we have worked hard to remove the numerous crashes and have a very stable application. Removal of Mono and Java rewrite/porting have been decisive and starting from RC5 we do not detect anymore the plethora of anr and crashes which plagued the previous versions. Anyway, if a crash occurs, it depends on its gravity: if the whole OpenVPN library is brought down, then Android will soon re-establish connectivity and your traffic will go outside the VPN. In every other case, for example if the communications between your device and the VPN server are interrupted, or your ISP renews the lease, you will not suffer leaks, because Eddie will either pause the VPN or "lock" the network. Kind regards

Will full AirVPN integration be in Eddie for Android when it releases from beta? Hello! The first integration is planned for version 2.0 coming out during October (initially as a beta version). Eddie Android edition 1.0 stable has the features you may have seen in RC5. The integration is particularly important because it can make Eddie work (at least with AirVPN) even in a device without SAF, so we are pushing for a quick development. Kind regards

Allow LAN/Private ticked indeed in both instances, leaving but one difference between the two versions over here, namely the empty Addresses Allowed box. Which your original answer kindly straightened out. Yours gratefully, PS - perhaps Little Snitch obfuscates these here LAN doings Hello! Yes, the problem must lie elsewhere. Again, we wish to underline that you must ignore the previous answer (it was deleted, but clearly the deletion arrived too late). The reason is that those options influence Network Lock behavior in its entirety, and NOT only in relation to the allowed addresses. A recommendation to the devs to cause Eddie to issue a warning when using those options has been already sent. Kind regards

Hello! Eddie Android edition has a much better leaks prevention than OpenVPN for Android. When Eddie Android edition exits the beta stage (stay tuned during this weekend...) it will be available for Android TV too. However, beware: some Android TV systems miss the SAF which is necessary to Eddie for the file chooser. Anyway if OpenVPN for Android runs in your Android TV device, Eddie will do too, because even OVPN for Android needs the SAF. In the future, Eddie will run even in Android TV versions featuring no SAF. Current status of Eddie Android edition: https://airvpn.org/topic/26549-eddie-android-edition/ Kind regards

Hello! By enabling "Allow LAN/Private" in "Preferences" > "Network Lock" Eddie window you already allow Bonjor protocol IP addresses. Since you experience a different behavior by Eddie 2.13.6 and 2.16.3 on this matter, would you please post two system reports generated by those Eddie versions, to let us investigate? We guess that you have kept the same configuration in both cases, is this correct? Kind regards

Hello! the quickest and safest solution is running the VPN client on the tethered devices. We provide five, simultaneous connection slots for each account. Kind regards

@rohko Yes, the important change to tun0 by the OpenVPN script is the DNS global scope and this is sufficient to have your system use only the VPN DNS. Eddie 2.17beta should not be used in your (and any similar) environment until the detected bugs are not resolved because you can't even patch the issue with the OpenVPN scripts, we're sorry. After all this is a beta version so it's not upsetting that bugs can come out. Please go back to Eddie 2.16.3 and keep using OpenVPN scripts which work impeccably. Eddie developers have been already informed, of course. Kind regards