Staff

Hello! Important: please note that under Linux Eddie can't disable IPv6 (it can do that only in WIndows and OS X). If you activate "Network Lock" Eddie will set ip6tables to block outgoing IPv6 packets. This thread is followed by Eddie developer, so the bug(s) you've found are being noticed. Kind regards

Thank you very much for your quick reply. Unfortunately, I have an unattended client and I do need to save the login details since at times nobody is around during startup. Are there any plans to implement this or have there not been enough requests? At the very least, Eddie could set more restrictive file permissions on the profile automatically, that would be fairly simple, although I would prefer the more secure way of using the specific OS APIs to handle this. Hello! No requests at all but this the correct way hands down, you're right. Kind regards

Hello! Thank you for your great feedback! Yes, just like browsers if you don't use a master password to encrypt all other passwords. This option is not currently available in Eddie. EDIT: the AirVPN.xml file although belonging to root:root is actually readable by every user, you're right. This needs to be fixed. You might like to not tick "Remember" in the login window: in this way the client will not store username and password and you can enter them anytime you run Eddie. Kind regards

Good! That could be due to the new tun/tap driver for Windows, do you run Windows? Kind regards

Port forwarding works just fine on Los Angeles servers. Kind regards

Hello! We released Eddie 2.9 as stable: https://airvpn.org/topic/14256-eddie-29-available Any pending issue in this topic will be addressed to version 2.10 experimental soon: we can't delay anymore all bugfixes between 2.8 and 2.9. Kind regards

Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.9. 2.9 version is compatible with several Linux distributions. For very important notes about environments, please read here: https://airvpn.org/forum/35-client-software-platforms-environments Eddie 2.9 includes bug fixes and changes meeting users' requests and preferences. It includes additional options for Network Lock to enable communications inside LAN and to allow ICMP, a new, reliable method to check DNS, an option for Windows and OS X to disable IPv6, connection to authentication servers via IP addresses instead of names and much more. Please read the changelog: https://airvpn.org/services/changelog.php?software=client&format=html Upgrade is strongly recommended. Just like previous version 2.8, Eddie implements direct Tor support for OpenVPN over Tor connections. Eddie makes OpenVPN over Tor easily available to Linux and OS X users: no needs for Virtual Machines, middle boxes or other special configurations. Windows users will find a more friendly approach as well. This mode is not handled anymore as a generic connection to a socks proxy, but it is specifically designed for Tor and therefore solves multiple issues, especially in Linux and OS X, including the "infinite routing loop" problem (see for example http://tor.stackexchange.com/questions/1232/me-tor-vpn-how/1235#1235 ) As far as we know, Eddie is the first and currently the only OpenVPN wrapper that natively allows OpenVPN over Tor connections for multiple Operating Systems. https://airvpn.org/tor We recommend that you upgrade Eddie as soon as possible. Eddie 2.9 for Linux can be downloaded here: https://airvpn.org/linux Eddie 2.9 for Windows can be downloaded here: https://airvpn.org/windows Eddie 2.9 for OS X Mavericks and Yosemite only can be downloaded here: https://airvpn.org/macosx PLEASE NOTE: Eddie 2.9 package includes an OpenVPN version re-compiled by us with OpenSSL 1.0.1k for security reasons and to fix this bug: https://community.openvpn.net/openvpn/ticket/328 Eddie overview is available here: https://airvpn.org/software Eddie includes a Network Lock feature: https://airvpn.org/faq/software_lock Eddie 2.9 is free and open source software released under GPLv3. GitHub repository https://github.com/AirVPN/airvpn-client Kind regards & datalove AirVPN Staff

Can you confirm that the recommended solution works? Kind regards

Hello, assuming that you can enable Network Lock, all Eddie versions since 2.5 should be blocking "WebRTC leaks". Eddie 2.5 was the first version to feature Network Lock. https://airvpn.org/services/changelog.php?software=client&format=html Kind regards

Hello, names provided by our DDNS are *.airdns.org. DynDNS is a service offered by Dyn Corp. and is another DDNS. There's no way they can use *.airvpn.org names, of course. theemim.airvpn.org resolves into Theemim entry-IP address according to the convention "server_name.airvpn.org" The doubts arose from that other IP address cited in the first message, 91.220.163.33. However, as Zaroad pointed out, the whole range 91.220.163,0/24 could be blocked by Malwarebytes. We just fell in that range with the IP addresses of this brand new server, not very lucky, but anyway we saw (probably you remember that) that Malwarebytes blocks enormous IP ranges for just one problematic machine: for example they blocked our frontend in Luxembourg as source of malware, and they confirmed, when inquired about that, that the block was correct because in that datacenter a different machine was spreading malware. Not exactly a fine grain defense for their users... EDIT: this is a funny thread from 2012 https://airvpn.org/topic/5061-mbam-webip-blocking-module-blacklist-airvpn-ips Given all of the above, we think than any person reading this thread can easily draw some conclusions about Malwarebytes. Kind regards

Thanks Zhang888, but it's not possible for us to get the whole /20 /21 subnet, because it is assigned to someone else and anyway it would be irrationally expensive for us for Spain (remember that Spain needs 20 Mbit/s for 35 customers at any given time...). We got "just" a /24 subnet RIPE update (and we actually use only of a portion of that). This one (46.182.35.0 - 46.182.35.255) is entirely and correctly geo-located to Madrid, so Bitcanal in our opinion operated correctly. Is there any reason (limited resources?) for which not even a /24 subnet is scraped after almost a year or even never (if you know) when two NETNAME are in the same AS? Only "big" subnets such as /20 are scraped? If so, geo-IP database maintainers are even more unreliable than we suspected, because with IPv4 exhaustion we think it's not so rare to put two NETNAME records with the same AS. Of course, if the remaining part of the /20 /21 subnet could agree to renounce to their NETNAME, then... but we think it's difficult, because they have another datacenter in Portugal and they probably need that. Kind regards

Hello! 91.220.163.33 is not one of our IP addresses. It is in the same /24 subnet of our new server in Ukraine, by the way Eddie does not send any packet to this specific address, but pings 91.220.163.44, i.e. one of the servers entry-IP addresses (to determine latency from your node and help you pick best servers for your system). But not to port 8. Before anything else, did you download the client software Eddie from our web site? Can you verify the downloaded archive fingerprint? Are you sure that this traffic activity is really toward that IP address, originated by Eddie, and to outbound port 8? And anyway this is not a new feature in Eddie, it was implemented even in previous versions. After you have made sure that you have a genuine Eddie copy, what happens if you disable pings from inside Eddie by unticking "Enable Pinger / Latency Tests" in "AirVPN" -> "Preferences" -> "Advanced" ? Kind regards

Hello giganerd! As we already wrote to the previous user, if the problem were with Nihal, we added a 2nd server in Spain well before his/her message, so this part of your new message is even more insensate. That's a terribly wrong approach for VPN servers, but it can be acceptable for closed servers only with "micro" routing purposes. However, we did not find any suitable datacenter in Spain during the last year, not even for micro-routing. Some due clarifications for you and the readers: - RIPE NCC is the only RIR for Europe, Middle East and some Asia areas, and it maintains the correct data for all Nihal IP addresses since almost one year ago - there is only one WHOIS version (see below). It is correct as well. We don't know what you're talking about. We talk about query of the RIPE database service via WHOIS. - the RIPE database correctly locates Nihal IP addresses in Madrid, Spain, where the server Nihal is actually located https://apps.db.ripe.net/search About the second server we added in Spain, we have not looked for a datacenter that pleases this or that TV or any other geo-discriminatory service, we have picked a network neutral datacenter, compliant to our requirements. We also tend to avoid contacts with datacenters which do not respect Net Neutrality, even if such a feature is not essential for a closed server only used for micro-routing, simply because it's not very elegant to give money to someone who is against our mission. Here is the WHOIS (40.439206460032445 -3.6216259002685547 are longitude and latitude of some point in Madrid). "geoloc" entry and all the other entries are correct since August 2014. Privately maintained databases, if what you report is true, are clearly not updated every year and even refuse corrections, even when the RIPE says they are wrong. ~$ whois 46.182.35.14 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '46.182.35.0 - 46.182.35.255' % Abuse contact for '46.182.35.0 - 46.182.35.255' is 'abuse@bitcanal.com' inetnum: 46.182.35.0 - 46.182.35.255 netname: PT-BITCANAL descr: Bitcanal PoP Madrid descr: Bitcanal INFRA-AW org: ORG-ETL18-RIPE country: ES geoloc: 40.439206460032445 -3.6216259002685547 admin-c: BAC13-RIPE tech-c: BTC14-RIPE status: ASSIGNED PA mnt-by: JS65083-MNT mnt-lower: JS65083-MNT mnt-domains: JS65083-MNT remarks: ********************************** remarks: ABUSE REPORTS MUST BE SEND TO ABUSE@BITCANAL.PT remarks: ********************************** created: 2012-11-08T11:25:41Z last-modified: 2014-08-02T09:54:46Z source: RIPE # Filtered organisation: ORG-ETL18-RIPE org-name: EBONYHORIZON TELECOMUNICACOES, LDA. org-type: OTHER address: Calle Albazans, 71 address: 28037 Madrid address: SPAIN phone: +351 912386351 fax-no: +351 220915985 mnt-ref: JS65083-MNT mnt-by: JS65083-MNT mnt-ref: ELT-MNT abuse-mailbox: abuse@bitcanal.pt created: 2014-08-02T09:51:05Z last-modified: 2015-03-23T10:49:31Z source: RIPE # Filtered role: Bitcanal Admin Contact address: Praceta da Geminacao, 19 - 1 Dir. Tras address: 4430-105 Vila Nova de Gaia phone: +351 224922637 fax-no: +351 224922637 remarks: trouble: Abuse Reports abuse@bitcanal.com remarks: trouble: Network Issues bitcanal.tech@bitcanal.com admin-c: JS9081-RIPE tech-c: MG12824-RIPE nic-hdl: BAC13-RIPE remarks: Bitcanal Administrative Contact mnt-by: JS65083-MNT created: 2010-11-18T15:27:31Z last-modified: 2014-02-05T10:30:58Z source: RIPE # Filtered abuse-mailbox: abuse@bitcanal.com role: Bitcanal Tech Contact address: Praceta da Geminacao, 19 -1 Dir. Tras. address: 4430-105 Vila Nova de Gaia phone: +351 224922637 fax-no: +351 224922637 remarks: trouble: Abuse Reports abuse@bitcanal.com remarks: trouble: Network Issues bitcanal.tech@bitcanal.com admin-c: JS9081-RIPE tech-c: MG12824-RIPE tech-c: VA4061-RIPE nic-hdl: BTC14-RIPE remarks: Bitcanal Technical Contact mnt-by: JS65083-MNT created: 2010-11-18T15:32:44Z last-modified: 2015-04-02T09:35:04Z source: RIPE # Filtered abuse-mailbox: abuse@bitcanal.com % Information related to '46.182.35.0/24AS197426'

Hello! Frankly we fail to understand the reasons of such a message. There are two Spanish servers and IP addresses of both are correctly geo-located in Spain by RIPE. They both have 1 Gbit/s uplink port and line. It makes no sense to have additional servers in Spain. They are normally used by less than 35 customers at any given time, and the required bandwidth is a tiny fraction of the total 2 Gbit/s available. For most time of the day Spain servers clients require less then 20 Mbit/s IN TOTAL. Therefore infrastructure in Spain is massively over-sized and there is absolutely no reason at the moment to enlarge it. Please click "Status" from our web site upper menu as usual for additional information. Click on a server name to see specific stats and additional data pertaining to that server. Kind regards

Hello! Authentication to our VPN servers is not based on username and password but on certificates and keys. The username and password you enter in our client are not used as credentials to connect to the VPN servers. Kind regards

Hello darkstar1707, when not connected to the VPN at least your secondary nameserver should be set to some public DNS server IP address because 10.4.0.1 is accessible only from inside the VPN. Set appropriate nameservers while Eddie is not running. We would recommend OpenNIC, please see http://opennicproject.org If your mails are not sent to port 465 or 587 (or any port different than 25) then a possible cause is that the SMTP server does not accept connections from our VPN servers. This is for example not uncommon with domestic ISPs which provide home connectivity as well as e-mail services: sometimes they accept usage of their mail services only from clients inside their own infrastructure. Kind regards

Hello! From the size of the address you wiped out in the screenshot it looks like an IPv6 leak. Our web site supports IPv6 but our VPN service does not. In your case, just enabling Network Lock (or disabling IPv6) with the options in our client should fix the problem immediately (remember to re-start a VPN connection). Kind regards

Hello! AirVPN is not vulnerable to DNS hi-jacking because VPN DNS server and gateway IP addresses match. The paper is outdated because their tests were performed on VPN servers with a /30 topology that we kept to maintain compatibility with Windows OpenVPN 2.0.9 and some older versions. After the draft paper preview they kindly provided us with months ago, we decided to speed up Windows OpenVPN 2.0.9 support drop, which made sense in 2010 but not now. Current topology allows to have the same IP address for VPN DNS server and VPN gateway, solving the vulnerability at its roots, months before the publication of the paper. Unfortunately they could not manage to fix the paper, purely for problems of time we suppose, which remained outdated. The quickest way to prevent IPv6 leaks with our service is just enabling Network Lock with a click, for those who don't want to disable IPv6. You can also disable IPv6 with a click, provided that you run our client Eddie for Windows or OS X (version 2.9 or higher is required; feature not available in Eddie for Linux). EDIT: we wish now to underline that since 2018 we also support IPv6 and IPv6 over IPv4. Kind regards

@darkstar1707 Hello! Outbound port 25 is blocked on all VPN servers, as specified in technical specifications published in our web site. This is the only exception we make to our Net Neutrailty respectful policy. It is aimed to mitigate spam e-mails. Please use alternative outbound ports (check your SMTP server settings: in many cases they listen to ports 465 and/or 587 for SMTP over SSL/TLS). About the other problem, you write that you have no connectivity out of VPN, but might it be simply a names resolution problem? Can you please check your system DNS settings? Kind regards

Hello, FTP servers and client work just fine in AirVPN. The FTP server requires specific setup due to how an FTP daemon maps ports for the client, please see https://airvpn.org/topic/1700-ftp-server-and-client-on-air-vpn/?do=findComment&comment=1702 Assuming that everything was correctly set on your side (and it seems it's ok, because little files can be transferred succuessfully), then the issue looks like an MTU size problem. Try with directive "mssfix". Insert mssfix 1400 in the "Custom" field which appears in "AirVPN" -> "Preferences" -> "Advanced" -> "OVPN directives", click "Save", start a new VPN connection and test again. If necessary, decrease the mssfix value at steps of 50 (for example "mssfix 1350", "mssfix 1300" and so on) until the problem is resolved. If the problem is not solved, then it's probably not an MTU size issue. Kind regards

Hello! That was answered in your ticket, we're curious to see alternative answers from the community without influence from us. Kind regards

Hello! "Lock current" is an option to re-connect to the current server during the current session. For your purpose you need to tick "Force reconnection to last server at startup" in "AirVPN" -> "Preferences". About the alleged crash, please make sure to shut the client down properly. What are your OS and your Eddie version? Kind regards

Hello! If in a VPN service you read "we have a server in country X", you expect: - that the server is physically located in country X or - that it can be located anywhere in the world, the important thing is that its IP address is located in country X by some database Nihal is in Madrid, Spain. In this specific case, it's also correctly located in Spain, since a year ago: https://apps.db.ripe.net/search/lookup.html?source=ripe&key=46.182.35.0%20-%2046.182.35.255&type=inetnum so there is absolutely no justification for wrong databases in this case. This is just another proof that a 100% reliable geo-location based on IP addresses is a myth. We comply to the first expectation: Nihal is in Spain, we report it as in Spain. Now consider this: fr1-ovpn.purevpn.net resolves into 94.249.174.130, GHOSTnet GmbH, that has servers only in Germany. Search in PureVPN http://www.purevpn.com/server_location.php for France. They list it under 'France' country. But, at least, they report this kind of server as "Virtual (Via Europe)". However, a lot of our competitors claim to cover hundreds of countries, when actually their servers are outside those countries and they have only re-located the IP address. We think this is not a honest behavior and that it is a disrespectful approach to customers. A honest VPN reviews website must ascertain and declare whether the provider lies about the alleged countries, or at least specify if the servers are really in the alleged countries or not. Kind regards

I just checked out Antares (Singapore) and Hadar (HK) 5 minute average charts for today. Earlier today Antares reached a peak of about 240mbit/s inbound and outbound (480mbit/s total) while Hadar is barely used. They are 1000mbit/s servers. I don't know if that's 1000mbit/s total or in each direction. Staff will have to answer that. If total, then that would mean that the 240mbit/s peak on Antares was still only half capacity (240 inbound + 240 outbound). If 1000 each way then it's only 1/4 capacity. So, I don't think any slowness can be blamed on Air. Hello! 1 Gbit/s is total. Only sporadically Antares is required to provide more than 600 Mbit/s. We see rare 600-700 Mbit/s peaks in the last months, so the server is almost never at capacity. Kind regards

Hello! We're sorry, we have no plans to add a VPN server in Italy. However, Sky Italia is accessible from all of our VPN servers, anywhere in the world, provided that you use VPN DNS. Please see also here: https://airvpn.org/forum/10-websites-support Currently RAI, Marco Polo, Leonardo, Lifestyle, Alice, Mediaset, Nuvolari, Repubblica, Gazzetta Sport, VVVVID, Videotime, Infinity and Cielo are accessible as well. Kind regards