Staff

Hello! The tun/tap interface (virtual network interface used by OpenVPN) does not come up... please try this: https://airvpn.org/topic/8320-solved-connects-but-ip-doesnt-change-on-windows-server-essentials-2012/?do=findComment&comment=8321 Also, upgrading to Eddie 2.9.2 might help with Windows Vista/7/8, because it will use a new driver for the interface which fixes various problems in Windows Vista/7/8. Kind regards

Hello, Tor proxy (just like any socks or http proxy) does not support UDP. OpenVPN will necessarily work in TCP. Please see also https://airvpn.org/tor Kind regards

Hello, do you get this error message even if you shut down Eddie with its own "Exit" option? Kind regards

Ok, great! What is your firmware? Did you compile stunnel by yourself for your router or is it an already available version? Kind regards

Hello! Since our servers will accept a variety of ciphers for SSL this is possible by configuring stunnel. However, configuring parameters for stunnel is currently not implemented in Eddie. Please see for example: https://www.stunnel.org/pipermail/stunnel-users/2013-February/004112.html Anyway, you probably don't need to bother about that. Nowadays computer CPUs are so powerful that they are not loaded at capacity by the current stunnel and OpenVPN ciphers you're using (well, it also depends on how much load they have from other tasks...). Kind regards

Hello! By default, all of your system traffic is routed inside the VPN tunnel once your system is connected to the VPN itself. If we understand correctly the problem, you would need to have only some traffic to certain web sites routed outside tunnel, so that those web sites see your real IP address and your traffic is not encrypted by the tunnel (i.e. not tunneled at all)? If so (but please make sure that we understood correctly!) you can do so in Eddie client menu "AirVPN" -> "Preferences" -> "Routes". Make sure that the combo box "Not specified routes go:" is set to "Inside the VPN tunnel". Then add in the window (by clicking the "+" icon) all the IP addresses of those web sites for which you wish the traffic is not tunneled. Action for them is "Outside the VPN tunnel". WARNING: all traffic to those IP addresses will not be tunneled. Not only "web traffic". Kind regards

Hello! Currently not, it's not meant as an alternative to Network Lock. In case of server switch or unexpected disconnection Eddie restores default gateway and nameservers, and only after that it tries a new connection. Kind regards

Hello! Because that's the date of the last changes, bugfixes and addition of new features. In April Eddie 2.9.2 Experimental exited the alpha testing and entered the beta testing. A few days ago beta testing was closed and Eddie 2.9.2 Experimental was promoted to stable. Kind regards

Hello! It's a bug (or more than one bug) in Mono. In the future, Eddie developer will consider to drop Mono and develop a GTK version. However at the moment this is not planned, we'll need a specific resource allocation for this task. Kind regards

Hello! IPv6 detection bug with error "Could not find a part of the path "/proc/sys/net/ipv6/conf/all/disable_ipv6" on some distributions will be fixed in version 2.10. Can you please elaborate? Can you show the logs about that and/or elaborate? Eddie for Linux can't disable IPv6. With "None" option it will not show the warning message. Eddie will set "None" in "IPv6" combo box after it has displayed the warning message. Thank you! Kind regards

They are the very same version, totally identical byte by byte. Kind regards

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