Staff

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Japan is available: Iskandar. This is the first server we operate in Japan, so a special name has been picked. Find the source for fun, the first person (with a valid account) posting the correct source of the name will get a 1 year plan for free. The AirVPN client will show automatically the 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 Air server, Iskandar supports OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello, as you might have seen the Zywall content filtering is blocking access to our bootstrap servers. Please upgrade to 2.14.2beta and open a ticket. Kind regards

Hello, starting from 2.14.2beta, Eddie does not use anymore the "--wait" iptables option. Kind regards

Version 2.14.2 [bugfix] Windows - Error "Windows WFP, Add rule failed: Interface ID '*' unknown or disabled for the layer."[bugfix] Crash in some menu items if opened before some initialization.[bugfix] Windows/Linux - Stats in title-bar.[bugfix] macOS - Settings -> Networking -> Layer IPv4/IPv6 regression bug[bugfix] Linux - RPM only - Removed libappindicator dependencyOther issues reported in this topic are still under investigation.

Hello! iOS doesn't, but Android does. Rooting not required. Please see here: https://airvpn.org/topic/24349-how-to-airvpn-via-sslstunnel-on-android-678/ for "OpenVPN over SSL" https://airvpn.org/topic/13486-ssh-tunneled-vpn-on-stock-android/ for "OpenVPN over SSH" Kind regards

Version 2.14.1 [bugfix] IPv6 activation issues[new] Added IV_GUI_VER to identify Eddie Version at server-level[bugfix] Linux - Tray and "Allow Minimize in Tray" fixed.[bugfix] Linux - iptables --wait flag workaround.[change] Don't show the No-Bootstrap dialog if occurring during connection.Other issues (memory management under Linux/Mono, tray icon under some distro etc) and feedbacks on this thread are currently under investigation for the next beta release.

Hello! The problem has been resolved. We deeply apologize for any inconvenience. Kind regards

Hello, please see here in order to avoid common pitfalls when you measure memory (even resident memory) usage of a process: https://stackoverflow.com/questions/131303/how-to-measure-actual-memory-usage-of-an-application-or-process Can you confirm your quote after you have taken care of the above (make sure to not measure the resident shared memory etc. etc.).? Kind regards

@InfiniteInt Eddie 2.14beta allows entering custom manifest URL (for example if Fortinet blacklists all auth servers), as you might have seen in the changelog. It looks like you just need this new feature. Please open a ticket. Kind regards

Hello! A lower score will translate into MORE stars. You should prefer servers with a higher amount of stars. Kind regards

Hello, please make sure to delete AirVPN.xml, the configuration file.. Kind regards

@airvpn88 Hello, you might consider to run Eddie with Network Lock enabled. In this way you will prevent any possible traffic leak outside the tunnel and Eddie will also re-connect automatically when the connection is lost. If you don't have a graphical environment in your Debian system, Eddie can also run in "command line" mode. Kind regards

Yes, please see https://airvpn.org/topic/25148-ipv6-support-experimental-phase/ Kind regards

The testing group confirms it's fixed.

Hello, the bug has been fixed. We apologize for any inconvenience. Kind regards AirVPN Support Team

Hello! Thanks, we are checking and fixing. Kind regards

What about the issue "Your browser is avoiding IPv6."? If you use AirVPN servers with IPv6 support: http://test-ipv6.com: You should obtain a score 10/10. With a single warning: http://ipv6-test.com/: You should obtain a score 15/20. The penalty is caused by The reason of the issue is explained here by jd890123 (thank you!): https://airvpn.org/topic/25140-the-issue-your-browser-is-avoiding-ipv6/?do=findComment&comment=81694 A quick workaround is also suggested. The issue does not affect Android systems.

[Windows] Why are IPv6 DNS not pushed by our servers in some cases? This topic explains why, only with Microsoft Windows and only if Eddie is a version older than 2.16.3, Eddie sometimes shows this message: Detected an OpenVPN bug (On-Link route on VPN range), autofix. Explanation This issue occurs ONLY under Windows. Sometimes (the problem is not systematically reproducible) after the VPN connection, inside IPv6 routing table entries you can see routes in identical ranges with different gateways: >route -6 print ... 38 259 fde6:7a:7d20:16::/64 On-link 38 259 fde6:7a:7d20:16::/64 fe80::8 ... When this occurs, DNS6 can't be reached with subsequent delays and issues. >ping fde6:7a:7d20:16::1 Pinging fde6:7a:7d20:16::1 with 32 bytes of data: Destination host unreachable. We think the problem is caused by an OpenVPN bug (at least in 2.4.4), currently under investigation. Current workaround Eddie automatically detects the issue and resolves it. For those who don't use Eddie (and generate .ovpn files with Config Generator), our servers don't push DNS6 directive if Windows (or older versions of Eddie) is detected, until the issue is resolved in OpenVPN code.

UPDATE 06.06.18: EDDIE 2.14.5 HAS BEEN RELEASED AS "STABLE" VERSION Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.14beta. It is ready for public beta testing. To download Eddie 2.14beta please select "Other versions" > "Experimental" from the download page. Please see the changelog: https://eddie.website/changelog/?software=client&format=html -------------------------- This version is released in combo with a new server called Castor (Belgium) that supports IPv6, tls-crypt modes and other features. For more information about the IPv6 experimental phase, read the thread IPv6 support - Experimental phase Note: please make sure you don't have IPv6 disabled on your OS before the tests (at OS level or at network adapter level). Improved notification will be implemented in the next release. Please talk in this thread only about Eddie 2.14beta NOT related to IPv6 or tls-crypt support. Rely on IPv6 support - Experimental phase for issues related to Castor. -------------------------- Eddie is free and open source software released under GPLv3. GitHub repository https://github.com/AirVPN/airvpn-client Do not hesitate to write in this thread if you decide to test Eddie 2.14beta and you find some glitch or bug. Kind regards & datalove Air Staff

UPDATE: EXPERIMENTAL PHASE ENDED. PLEASE SEE HERE: https://airvpn.org/topic/28153-ipv6-support/ We are glad to inform you that a new experimental server called Castor is now publicly available, with a series of new features: Standard protocols/ports with IPv6 support, updated OpenVPN server, better cipher negotiationAdditional protocols/ports with IPv6 support, updated OpenVPN server, better cipher negotiation, 'tls-crypt' directive, TLS 1.2 forced These additional protocols/ports require OpenVPN 2.4 or higher versionInternal load balancing between OpenVPN daemonsNew DNS server engineYou can experiment with Castor in two modes: Using the latest Eddie 2.14betaUsing our Config Generator (check 'Advanced' in top-right corner for IPv6 and tls-crypt options)Notes: The new server is marked as 'Experimental' and will not be proposed by default (opt-in).Don't rely on Castor during the experimental period, we might need to reboot it to fix newest issues.There is a bug related to Castor IPv6 DNS that occasionally affects only Windows. See the topic Why in special cases DNS of IPv6 are not pushed by our server. For this reason IPv6 DNS is disabled by default only with Config Generator. Eddie implements a workaround for this issue.A lot of websites that perform IPv6 check can report false-positive, or in general browser may not use IPv6. See the topic The issue "Your browser is avoiding IPv6." for more information.After the experimental period and when Eddie 2.14 is released as stable, we will upgrade every VPN server (where possible, since some of our ISPs don't have IPv6 infrastructure) to be based on Castor server-side software. Please talk in this thread only about Castor issues, Config Generator or Eddie related to IPv6. Rely on Eddie 2.14beta topic for other issues related to Eddie

Hello! First of all thank you very much for your long term subscription. We're glad to know that you managed to solve the issue. Enjoy AirVPN! We don't have any problem with Avangate and/or PayPal. Remember that when you sign a contract to be able to use a credit card, you explicitly accept the fact that every merchant has the right to book your funds and then NOT accept your payment if you refuse to provide a valid ID document, when they can't verify the proper signature of the card (which is always, in the online world). We guess that in the online world such a legitimate right is exercised in an attempt to prevent the huge amount of frauds which are attempted every day online and offline. Fair or unfair condition, credit card emitters grant a merchant the right to ask for an ID (but only when the merchant can't see the customer in person and verify the proper signature, in general). In some countries, showing an ID is always mandatory, even if the merchant can see you and the card physically and check the signature. We're also sorry to say that we can't accept cash. It would be humanly impossible to link a cash payment to some account and activate it manually without dozens of persons specifically dedicated to this work all day. Maybe a solution for tiny businesses with just a few thousand customers, but not for us, it would imply an incredibly enormous economic and time effort. Also useless, because cryptocurrencies work much more efficiently, quickly, smoothly and securely than a snail mail with cash inside. Again, thank you for your patience and thank you very much for your choice! Kind regards

Hello, some hints: do you notice packet errors in the OpenVPN logs? Do you have some packet filtering or QoS tool active in the router and/or in the system where the torrent client runs (including the traffic shaping tool of the torrent software itself)? When you don't run the torrent software, is the throughput stable (try a long download in FTP for example)? If you set (in the torrent software) a limit on upload to 50% of your nominal peak upload throughput and 75% to your nominal peak download throughput do you notice any improvement? Kind regards

Yes. And the 192.168.x.x addresses will be provided via another OpenVPN connection. Hello! 192.168.0.0/16 is a private subnet. Devices already in the subnet are already in your private network, it would make no sense and it is would be also very challenging to route the local traffic onto the Internet just to receive it back in the very same private network. Why should you want to make a packet for your printer travel thousands of miles when it can travel a few meters and remain not exposed on the Internet? If you mean, instead, that you want to access your local network from the Internet, and therefore create a VPN to share devices and resources which are inside your local network from external devices in a secured environment, then you need to setup a VPN server, so that all the devices (inside and outside your physical local network) will be connected to the same virtual private network... but this has little or nothing to do with AirVPN. Kind regards

Hello! Understood. You need to consider the slow adoption of DNSSEC. A remarkable amount of registrars do not offer DNSSEC option, and those who do, do not offer any support for creating and signing DNSSEC keys. See https://www.statdns.com/ This is an executive summary (with the omission of inessential details for the readers) of a brief report elaborated last time we had to assign a priority to DNSSEC support. It was an overview not entering the technical, operational challenges in details. Such challenges were postponed to when the general benefit-cost ratio were deemed as acceptable when compared to all the other priorities (keep in mind that not only we do not outsource customers support, but obviously we never outsource any management or configuration of our machines). Pros: obvious: increased reliability of names resolution with the authoritative DNS supporting DNSSEC preventing tampering of resolutions between our DNS server and the authoritative DNS of those names [which are signed] (...) unfortunately a low percentage, as you can see in the charts (...)the increased traffic flow of queries and replies will be 2-4% (...) negligible.Challenges: frequent outages of DNSSEC worldwide (see report) will impact user experience. (...) What to do: Google DNS fails with SERVFAIL but:"However, if the impact is significant (e.g. a very popular domain is failing validation), we may temporarily disable validation on the zone until the problem is fixed." (sic, official from Google). How can our resolvers decide properly which domain is "very popular"? How should we disable DNSSEC for an entire zone without making DNSSEC a cause for a false sense of security? (...) Manual intervention will be overwhelming (....) not viable Carefully configured negative trust-anchors, provided they are sufficiently reliable to rule out malicious activity, should be mandatory as long as the outages remain frequent. enlargement of surface attack (see enclosed Akamai security bulletin), specifically (...) DNS amplification DDoS (...) requires configuration attention and even higher than current analysis of DNS resolvers vulnerabilities "Careful with that axe, Eugene!" re-consider micro-routing in order to preserve itCons: misconfiguration of a significant percentage of DNSSEC (...) can lead often to names resolution failures, impacting user experience: what to do when DNSSEC is active, but not RFC compliant, causing issues to the resolver? A solution should be found for (...) a significant percentage of customers will not be able to understand or discern the fact the we should not be deemed "guilty" for third-party misconfigurations when [users] can't resolve names that they could normally resolve before. A reaction to seriously consider is that DNSSEC could be seen as a degradation of our service quality (...) We should not rely on the hope that suddenly [so many] misconfigured [systems] will be all efficiently fixed.Dubious: re-consider anti-ICANN/ICE censorship circumvention with illegally seized domain names etc. in order to not affect the systemconsider the report from RIPE (...) higher CPU load for names resolutions. While the percentage of DNSSEC-compliant names is little an impact assessment is probably necessary anyway given the fact that we are already pushing CPUs to provide 1 Gbit/s AES-256 throughput etc. to multiple ovpn clients. (...) Impact on throughput, which is essential to most of our users and a founding basis of a comfortable experience, should maintain the current, high priority.. RIPE provides some data (...) about 5% higher CPU load for resolutions. If confirmed, impact on our servers is acceptable if not negligible.More data on outages: https://ianix.com/pub/dnssec-outages.html Fringe view (not in the original report): https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/stuff/dnssec-qa.html and so on. At that time, the DNSSEC issue was given a priority lower than IPv6 deployment, improvement of Eddie, patch of OpenVPN bugs, and many more features you have seen implemented during 2017, because the benefit-cost ratio appeared not as good as other matters which were objectively more urgent. Please note that the report has been elaborated a year ago so we will re-discuss the matter, of course, because some of the problems might have been mitigated after a year (maybe misconfigurations have been fixed, maybe outages have become rare) AND because after IPv6 deployment we will switch to (in our opinion) better DNS resolver. We will probably re-schedule the whole matter after IPv6 and DNS resolver deployment. As a side note, we have received a private question from one of our users which shows a potential confusion, so we underline that all the DNSSEC issue has nothing to do with the reliability with the DNS queries and replies to and from our DNS servers. Each VPN server runs its DNS server and all the queries and replies to/from your node are encrypted (tunneled in the VPN) so nobody in the middle (not even your ISP), i.e. between your node and our server, can tamper them. Kind regards

Hello! About the following entries: Jan 29 18:23:06 DD-WRT daemon.warn openvpn[8830]: WARNING: file '/tmp/openvpncl/client.key' is group or others accessible Jan 29 18:23:06 DD-WRT daemon.warn openvpn[8830]: WARNING: file '/tmp/openvpncl/ta.key' is group or others accessible the fix (if you find it really necessary...) must come from you side by setting the attributes you wish for those files. About this: Jan 29 18:23:08 DD-WRT daemon.warn openvpn[8833]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this you can safely ignore it because authentication is not based on passwords. Kind regards