Staff

Hello! Please enable "Log debug" in "Preferences" > "Logging". It will increase log verbosity which could provide some clue about what happens (feel also free to send the log or even better a system report, even in a ticket). EDIT: also, while Eddie is not running, you might rename the file ~/.airvpn/default.xml (root access is needed to do that). It's Eddie configuration file. At the next run Eddie will create a new default.xml file with all default settings: check whether the problem gets sorted out or not. Kind regards

Hello! Please see here: . 2018.10.23 13:12:26 - Cannot retrieve systems & servers data. (curl: (7) Failed to connect to 127.0.0.1 port 9151: Connection refused - with 'socks' (always) proxy and 'none' auth) and here: 2018.10.23 13:12:42 - OpenVPN > Attempting to establish TCP connection with [AF_INET]127.0.0.1:9151 [nonblock] You have configured Eddie to connect over some proxy running in your system but your proxy is either not running or not listening to localhost port 9151. Please check your proxy settings. If you did not mean to have Eddie and OpenVPN connect to some proxy, check the settings you have modified in "Preferences" > "Proxy/Tor". Kind regards

Hello! We can't reproduce this issue. For further investigation please open a ticket. Kind regards

Hello! Yes, this is planned in a very near future. Kind regards

Hello! Thank you very much for the report, a bug fix is needed. The issue occurs only on Android 6 and has been confirmed. Kind regards

There is no problem on our end. The misconfiguration of imdb.com DNS has been confirmed twice by two different specialized services. Of course this is a different problem than the blocking one (when our servers are blocked by imdb web server and/or imdb authoritative DNS) but both of such problems are on imdb side. On our side we can only intervene with tricks to bypass blocks of the mentioned second scenario. Also it is not true that you can connect merrily to imdb.com without AirVPN. We detect the identical problems from Italian ISPs (using ISP DNS) residential lines. Kind regards

I noticed the same thing. Only one Vancouver server now. What happened? Hello! Getting rid of datacenters/providers that can keep their promises only for a few weeks. It looks like we did not get a good service in the Vancouver area in the last 8 weeks or even more (confirmed by users feedback) so radical changes have been mandatory. We will expand infrastructure in Vancouver with the Pisces ISP in two weeks if there are no issues (at the moment Pisces meets our requirements). Kind regards

Hello! Multiple blocks are enforced: and a general UDP and/or OpenVPN block. Even if the authorization check fails Eddie can go on by using the latest available info retrieved from your HDD. Such info will be updated once inside the VPN, when all the blocks are ineffective. Please try the following settings: from Eddie main window select "Protocols" > "Preferences"untick "Automatic"select the line with entry-IP address 3, protocol TCP, port 443 (the line will be highlighted in blue)click "Save"test connections to various servers in various locationsKind regards

Hello! The imdb.com misconfiguration is explained in the thread mentioned by psychlops: https://airvpn.org/topic/29835-problems-with-imdb-dns https://dd.us.imdb.com (which is also imdb.com CNAME record) seems correctly configured so you can point to it if the problem on their side goes on. Kind regards

Hello, if the fact (losing the servers score displayed by the stars) occurs when the system is connected to the VPN that's expected and intended for obvious reasons. Kind regards

Hello! The problems showed by MXToolBox are confirmed by https://www.dnsqueries.com/en/domain_check.php (we don't know why you mentioned our servers since the problem you correctly point out is in imdb.com). Note in particular, in the WWW section of dnsqueries.com check page, this: Kind regards

Hello! Two distinct problems probably. The second one would be a block of some IP addresses of our VPN servers (check the "Route check" page and see). We will look into the issue. Kind regards

Hello! Maybe you try to access Netflix from a device which is behind the Raspberry box. In this case please check the DNS settings of such device, which of course take precedence over the Raspberry DNS. Kind regards

Hello! If you run OpenVPN directly you should consider some script to take care of the DNS push (OpenVPN will not process the DNS push by itself). Please check here: https://wiki.archlinux.org/index.php/OpenVPN#Update_resolv-conf_script Kind regards

Hello! This is unexpected and deserves an investigation, thank you for the head up. EDIT: we're sorry, the account does not have any forwarded port and/or any linked name for our DDNS. Maybe you use different accounts. Please open a ticket to clarify and let us check the issue. Kind regards

Please do not hijack threads, this has nothing to do with the OP problem. Exit-IP addresses of VPN servers are shared, this feature is intended and a key to enhance the anonymity layer. Kind regards

Hello! Can you please test Eddie 2.17.2beta? This issue (Network Lock takes several minutes to be applied because each iptables call takes a long time, like 300 ms) appears resolved: https://airvpn.org/topic/29570-eddie-217beta-released Kind regards

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