Staff

Hello! This problem should have been resolved in IMDB side, but the other problem (authoritative DNS servers blocking our DNS servers in some VPN server) is probably still ongoing. Can you tell us which VPN servers you experience this problem on (each VPN server runs its own DNS server)? Kind regards

Yes, a possible explanation and a solution to the issue (tested as working on TV/media players with hard coded Google DNS) are suggested in the previous message. Can you test and report back? The suggested pre-routing can potentially solve the issue even if it's the Netflix application the one forcing DNS queries to some specific DNS server. Kind regards

Hello! A plausible explanation is that some Netflix app forces DNS queries to some specific DNS, bypassing system settings, or some TV box has hard coded DNS (like it happened with Roku3 which incredibly had hard coded Google DNS). The queries are tunneled in the VPN anyway, but they are forwarded to the final DNS server. In this way you don't use the geo-routing system and you can't access Netflix. A possible solution is using a DD-WRT / Merlin / Tomato / pfSense etc. router to connect to the VPN and pre-route any DNS query (after you made sure to not connect to our servers on port 53) to the VPN DNS. For example: iptables -I PREROUTING -t nat -p udp --dport 53 -j DNAT --to-destination 10.4.0.1 iptables -I PREROUTING -t nat -p tcp --dport 53 -j DNAT --to-destination 10.4.0.1 Kind regards

Hello, thank you very much to both of you, the crash report is precious. We are warning devs about this thread. In the meantime you can try to delete the file "default.xml" while Eddie is not running (the file is in your ~/.airvpn directory) and start Eddie from scratch. Since one of you said that Eddie did not crash during the first days of usage, we can't categorically rule out that the crashes are consequence of some bug causing a configuration file corruption. default.xml is Eddie configuration file. At the next run, Eddie will re-create it with default settings, so you will need to re-enter your credentials. Please keep us posted. Kind regards

Hello! It's a known bug which has been fixed in 2.17.2 experimental version. The bug does not affect significantly Eddie operations but on the long run can remarkably slow down initial connections. If you decide to test Eddie 2.17.2, please see here for download instructions and detected issues: https://airvpn.org/topic/29570-eddie-217beta-released Kind regards

Hello! Can you please check the output you get in a terminal emulator when you try to run it? For example with sudo /path/here/eddie-ui Kind regards

Hello! It's a delicate matter. The suggested method, which is a trademark if you didn't notice , will harm customers security and AirVPN industrial secrets as well. "Security through obscurity" is "the reliance on the secrecy of the design or implementation as the main method of providing security for a system or component of a system.". It is trivial and obvious that when secrecy is not the only security method, it can be extremely helpful for security as well as other purposes. It's a macroscopic and logical mistake to believe that to not rely on "security through obscurity" you must have no secrets at all. Under the current terms, the whole matter looks like marketing fluff aimed to promote a trademark and maybe gain some more customers. Ironic that those who promote access in read-only mode into their servers and recommend publication of all algorithms implementation feel the need to trademark two common language words. On top of that, it looks like you can't even access their service if you don't run their software. If you are in mobility, you also need an Apple or Google receipt, so they force you to use either Apple or Google stores. Wow, that's openness and respect for users' privacy, sure. To get into more details: 1) Our industrial secrets are not rocket science. However, we have seen that our competitors in many years have not been able to have an infrastructure working on a par with AirVPN architecture, so our industrial secrets are valuable and we will not throw them away by allowing access in read-only mode inside our servers or by documenting our secret algorithms or in any other way. 2) Harm customers security. By allowing inspection or documenting the exact implementation of our security features and algorithms we will remarkably lower our customers security. For example, backend servers will become of public domain as well as the reverse proxies allowing indirect communications to service and VPN servers up to the backend servers. The whole path would be discovered and having compartmentalized databases (which, alone, is an important security feature) on servers unknown to the public, would be destroyed at once. The architectural security principles are already documented in the Privacy Notice, in strict compliance with GDPR, which would enforce such documentation and implementation in case we handled personal data. We do not even handle personal data so the additional security features are a proof of our commitment to your security. That said, knowing in details the technical implementation of said features, the exact locations, addresses and non-root access credentials from the Internet of our strategic servers, and the original algorithms, invented for a wide variety of purposes, which make AirVPN unique, is a dangerous madness. Kind regards

Hello! Please try the following connection mode (OpenVPN 2.4 or higher version is required): - from Eddie main window select "Preferences" > "Protocols" - untick "Automatic" - select the line with entry-IP address 3 (THREE), protocol TCP, port 443 (the line will be highlighted in blue) - click "Save" and test connections to various servers in various locations Kind regards

Understood. Well, thank you anyway for having offered a staff member the chance to point out so many NordVPN security flaws and missing features. We confirm they are coming. Kind regards

Hello! Already answered, please read https://airvpn.org/topic/30935-eddie-android-edition-201-released/page-2?do=findComment&comment=80787 Kind regards

Still no reply to the above. Hello! This thread is reserved to Eddie Android edition. Eddie Android edition accepts ovpn profiles (of any VPN provider, of course) since its birth. An Eddie Android edition without this option has NEVER existed. Kind regards

Hello! It's just a way to say that, directly from inside the server, we are investigating minor issues which must be investigated but do not affect significantly server operations and do not justify a forced, abrupt disconnection of the connected clients. We might perform limited operations with an impact (for a limited time) on server performance, that's why it's in "yellow" status and therefore not recommended for connection. Kind regards

Hello! "Same thing" is frankly offensive for AirVPN. It's also astonishing that someone can have the idea to compare such profoundly different services. Power of marketing fluff aimed to gullible people, we guess. Just to make a few examples, NordVPN lacks separate entry and exit IP addresses on many servers (various types of correlation attacks become possible), does not support IPv6, provides a ridiculous/non-existent servers monitor, provides fake servers locations, infringes net neutrality (does not allow any p2p protocols on a wide range of servers), does not provide dynamic remote port forwarding, does not provide DNS inside the VPN whose address matches the VPN gateway (exposing to DNS poisoning through route hijacking), is not GDPR compliant, is owned by a Lithuanian data mining company and has ties with Russian oligarchs. AirVPN prices are competitive even without a special deal, check our new two years plan and anyway stay tuned for Christmas special deals. Kind regards

Hello! Provided that you enable Network Lock, removing the default gateway is not necessary and not even an optimal solution. By default Eddie must have this option UNCHECKED in every system, did you notice otherwise in beta versions? Kind regards

Hello! Currently our VPN servers are configured to not use compression, so you can't use LZO or LZ4 with AirVPN. Some old compression vulnerability is therefore resolved at its roots. Furthermore, the incompatibility between "comp-lzo" and "compress" directives (a mutual incompatibility which sooner or later might have a dramatic impact) should be more easily solved in due time. Kind regards

Hello! LAN access while Eddie is connected is not possible, we're sorry. We have planned LAN access for a near future Eddie release. Kind regards

Hello! Nobody is a "pain", don't worry, the support team job is exactly supporting any customer experiencing any issue. Please try the suggested solution, according to a report (well, it's just a single report, but from a reliable source) the recommended connection mode works from Thailand. Kind regards

Hello! With quick connect as well as manual server choice Eddie must fall back to TCP when UDP is blocked, provided that the user did not force UDP in the settings. Specifically, Eddie must try a connection over TCP to ports 443 if attempts in UDP to port 443 and 53 have failed. Can you please make sure that you have not forced custom configuration in "Settings" view? Please feel free to report back. About "Restore last profile at boot", can you also tell us your device and Android version? Kind regards

Hello! Eddie can't count on the options you mention since it must prevent leaks even in Android versions older than 8 (from 5.1 to 7.x). However, if you can start a VPN application at boot, the options you mention (in Android 8 or higher versions), when active and when the VPN application had already started at boot and never terminated during device usage (otherwise the block will not work anymore), should ensure an equivalent leaks prevention. We need a deeper experimental testing to confirm or deny. Currently we can not say with absolute certainty that your described setup leaks prevention is equally effective than Eddie lock method. Eddie can start at boot, when "Restore last profile at boot" is active, so the Android 8 new VPN related options umbrella can cover Eddie as well, but of course Eddie will super-impose its own communications lock in case of fatal OpenVPN connection error. Kind regards

Nice; but I wonder why that option is only available on Android, and not on PC, when Android is a more restricted platform (without root). Unless it is available, and I am missing it. Hello! This feature might be implemented in a near future on Linux systems and maybe Mac and *BSD. However, such implementation in Windows is challenging or, perhaps, impossible, unless you think of vicious, deranged solutions like code injections to bind binaries to a certain network interface. The cause lies again on Windows bad architecture: it does not even support features which are nowadays quite obvious in modern systems, such as multiple routing tables. Going back to GNU/Linux, thanks to cgroups, traffic splitting on an application basis is already available to all AirVPN customers, in the software "Qomui", developed and programmed by corrado, who is also a member of AirVPN community, in Python. Qomui has reached a very good integration with AirVPN. Please see here: https://airvpn.org/topic/26327-alternative-airvpn-client-with-provider-independent-double-hop-support-gnulinux/ Kind regards

Hello! The KEEPALIVE_TIMEOUT error is not recoverable since it implies a lack of communication between client and server higher than the maximum alive time (60 seconds in our service). After this error OpenVPN exits, so Eddie must lock before it's too late (i.e. before traffic starts to leak outside the VPN tunnel). If you have this event 5-15 times a day, then Eddie saves you from traffic leaks outside the VPN tunnel 5-15 times a day. Kind regards

Hello! Different aim and scope and also a nice idea. It's based on Tor too, although scaled down so that a single tab of a single browser of your system communicates with a remote desktop acting as an interface to Tor network . If you use Tor (directly in your system we mean) you get a stronger anonymity layer, while with a VPN you can tunnel the whole traffic of your system. On top of that, you need to consider that with Tor or VPN you can run your own programs locally, which in many circumstances can be a nicer solution. When using a remote desktop not owned by yourself you also need to consider that end-to-end encryption with final services is performed by the remote desktop, and not by your system. So, those who have access to the sadd system may potentially have access to all of your "end-to-end" encrypted communications, because one of the ends is not your system but the remote desktop. Probably not acceptable in most circumstances. Kind regards

Hello! it looks like you still miss the point. Wireguard, in its current state, not only is dangerous because it lacks basic features and is an experimental software, but it also weakens dangerously the anonymity layer. Our service aims to provide some anonymity layer, therefore we can't take into consideration something that weakens it so deeply. We will gladly take Wireguard into consideration when it reaches a stable release AND offers at least the most basic options which OpenVPN has been able to offer since 15 years ago. The infrastructure can be adapted, our mission can't. We provided a list of missing features causing real, objective security flaws in Wireguard (when meant to provide specific features). We will expand them here below since it looks like you missed the huge implications of the mentioned issues. It's not a matter to "cover their asses" as you say. First, it's a matter of security. If you followed some basic IT security principle, you would know how wrong and dangerous a claim like the one quoted here above is. If you are really in the position to certify that "Wireguard is fine", then do it officially. If you can't do it officially, your words must be considered irrelevant, because they go against the claims of the very Wireguard developers themselves. Second, it is a matter of lacking features that are essential for any service which aims to provide a decent layer of anonymity. Wireguard, in its current state, does not meet our requirements. Here below, once again, some points which need to be considered and addressed: Wireguard lacks dynamic IP address management. The client needs to be assigned in advance a pre-defined VPN IP address uniquely linked to its key on each VPN server. The impact on the anonymity layer is catastrophic;Wireguard client does not verify the server identity (a feature so essential that it will be surely implemented when Wireguard will be no more an experimental sofware); the impact on security caused by this flaw is very high;TCP support is missing (third party or anyway additional code is required to use TCP as the tunneling protocol, as you suggest, and that's a problematic regression when compared to OpenVPN);there is no support to connect Wireguard to a VPN server over some proxy with a variety of authentication methods. Kind regards

Hello, you don't need to link OpenVPN against OpenSSL. For example in Android we link it against mbedTLS. Kind regards

Hello! Please see here: https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables Kind regards