Staff

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

Hello! IPv6 full support is imminent, This will solve any issue for persons who have IPv6-only lines, regardless of the device they use. Please note that a proper IPv6 support based on OpenVPN is currently not available in any VPN service in the world, except maybe one. All the services are based on IPv4. Our development team was even forced to rewrite OpenVPN to fix bugs which prevented a real IPv6 support. IPv6 support was planned for the end of 2017 but has been postponed due to new discovered bugs. In spite of all these problems, we're optimistic about releasing the first IPv6 supporting server in a matter of days. This is FALSE, contrarily to the names of almost every and each of our competitors, airvpn.org passes all and every DNSSEC analysis, See by yourself: https://dnssec-debugger.verisignlabs.com/airvpn.org airvpn.info does not, but it's a fall back name (anyway in the future airvpn.info will be signed with DNSSEC too). We are confident that this is irrelevant for the VPN service in itself. Kind regards

Hello! You were right, Cygnus went down but the nl.vpn.airdns.org name kept resolving into Cygnus entry-IP address because the monitoring system failed to detect the problem. Therefore Cygnus resulted with low load and soon escalated to have the highest rating first in the Netherlands and then in the whole Europe (europe.vpn.airdns.org). We deeply apologize for the inconvenience. Such occurrences are anyway very rare because the monitoring system has been very much refined in the last 5 years. Kind regards

So there is absolutely no possibility of a "non-Eddie preview" with just server access so that those of us who do not use Eddie can see how things will be? Hello! We don't rule out this option, although we would prefer a simultaneous launch. Should IPv6 problems with Eddie cause a significant delay in 2.14beta release, we will seriously consider to open the new IPv6 supporting server before Eddie 2.14beta is released. Kind regards

Hello! We are providing a quick update on the status of IPv6 and new Eddie deployment. Just a the day before Eddie 2.14alpha was going to be promoted to beta version, two major bugs were discovered and confirmed as reproducible. Such bugs are critical in IPv6 so we were not able to release Eddie in beta version yesterday. Developers are working to identify and fix the code causing both bugs. First IPv6 full-supporting VPN server will be "open to the public" together with the release of Eddie 2.14.x beta. We are unable to set a precise release date as long as the bugs are not fully "understood and isolated" in the source code, but we will keep you informed on developers progress. Kind regards

Hello! We're sorry for the additional delay. We will publish an official announcement in the next 24/48 hours Kind regards

Hello! That's not correct. It should be queried, but only when the primary (and any previous) DNS fails to resolve a name. ipleak.net forces this situation to discover all the DNS servers that your system can potentially query. According to your description this is fine. Also, the queries to other DNS are tunneled as well, unless you use some Operating System which does not have the concept of global DNS and is therefore affected by the so called "DNS leaks" (typically, only Windows: in particular, DNS leaks do NOT exist in GNU/Linux). Also consider that the DNS settings of the devices behind the router "override" the router DNS settings. Kind regards

Hello! "Permanent" is not a proper adjective near "solution" in this context. Nothing is permanent. We will try but can we ask you why you like to pay people to have a service which actively blocks our VPN servers, showing you utter disrespect as they consider your privacy, a fundamental human right, not even worth to be protected by a VPN? Kind regards

Hello! We have several customers from China who can use our service with "OpenVPN over SSL" successfully. OpenVPN over SSH is usually successful too, but it is normally throttled more and it is also less efficient (stunnel is better than ssh under this respect). On mobile lines, in various cases avoiding UDP is enough (otherwise you will need OpenVPN over SSL on mobile devices too). Kind regards

Connection Type is set to sha512...but you don't explain it very well in your Details. Many here thought that you updated to SHA2. Well that is the way many would think. Hello! Yes, and that's correct. SHA2 is now the exclusive algorithm to generate the self-signed certificates (both on client and server side). No, any new pair will no more be generated with SHA1. Note (just in case some confusion is arising here) that the digest HMAC SHA1 for the OpenVPN channels packet authentication remains and will remain available: we have not and will not break compatibility with old OpenVPN versions. By the way, this is a separate topic, since HMAC SHA2 (specifically HMAC SHA384) has been available since a couple of years ago as a digest for the Control Channel (provided that you were running OpenVPN 2.3.3 or higher). Kind regards

Hello! First, please make sure that you run version 2.13.6 (check in "AirVPN" > "About" your version and upgrade if necessary). Then, from the main window, log your account out and log it in again. You should see (before you start a connection) a combo box "Device:", which will let you pick the keys you generated (the description you picked will be shown). Kind regards

Hello! Not exactly, since the Control Channel of OpenVPN maintains HMAC SHA1 available as digest (HMAC SHA384 is available as well, starting from some version of OpenVPN). New Data Channel ciphers will be available as well. All the changes will be fully applied after IPv6 testing is over (internal testing is over and successful, public testing on at least one server will start in the very near future). A new https://airvpn.org/specs page will clarify all the new supported modes in due time. Kind regards

Hello! You can't change the integrity message digest: in the relevant phase, with the new certificate-key pairs, it will be always SHA512, not SHA1. Cipher is 4096 bit RSA as usual. Kind regards

Hello! We're very glad to announce that a new option has been added in your account "Client Area". You will find a menu item labeled "Devices / Keys". The "Devices / Keys" tab provides you with access to a new panel to administer your client certificate/key pairs. The panel lets you use a new multi-key support from AirVPN, a comfortable and convenient feature. From now on, you will be able to have multiple keys, renew them and issue completely new keys. From each device of yours you will be free to use any key you like. Therefore you can keep all of your keys under control, administer them and also connect multiple devices to the same server and port by using a different key on each device. Eddie 2.13.6 (current stable release) already implements in the Overview window a menu which will let you choose a key before you start a connection. It will appear automagically when you create a new key from your account control panel. The Configuration Generator has been modified as well, to let you generate configuration files with the certificate/key pair you wish. Let's see in details how to use the "Devices/Keys" options. Device Name and Description: this is a free name or description that you can associate to any key for your comfort.Columns Type, Creation date, Last renew date and Last VPN connection are informative.Renew: this is an action button. When you click it, the corresponding certificate/key pair will be revoked, and new ones will be issued.Delete: this action button will revoke the corresponding certificate, without issuing a new one.Add a new key: this action button will create a totally new certificate/key pair which will be added without revoking or renewing any pre-existing key.View history will toggle with View Active to provide you with any relevant information on the history of your actions about keys and the current active list. Some caution when using these new features: if you revoke or renew a certificate/key which is being used by some connected device, that device will soon be disconnectedin Eddie, you will need to log your account out and then in again to force Eddie to pick a different key (new or old) Kind regards and datalove AirVPN Staff

Hello! That's expected and intentional. Eddie does not set "permanent" iptables rules, they will not survive a system reboot. Kind regards

Hello! iptables rules restored when you close Eddie: intended and expected. When Eddie crashes, we can't see how it can modify iptables rules or do anything else. Network Lock is a set of iptables and ip6tables rules, please feel free to clarify. Kind regards

Hello, you can also use gdebi, which resolves dependencies automatically. Or just right-click the icon of the .deb package and select "Open with" > "Software install" (or any similar item). Kind regards

Hello! Yes. Kind regards

Hello and Happy New Year to you too! IPv6 support on server side will be available regardless of the software client used to connect to our VPN servers. We can't categorically rule out that some clients might have problems. We hope not (and we will be testing as soon as our ISPs in Italy provide us with a more decent IPv6 support), but in any case (hear, hear!) we are willing to release Eddie for Android within July 2018 with a lot (if not all!) of the features you find in Eddie for desktop systems. The problem you mention is serious and we think that it might become a widespread issue for mobile users in several countries in 2019. This is the main driving force which convinced AirVPN management to speed up implementation of IPv6 support. Going back to 2014, IPv6 support was vaguely road-mapped for 2019/2020. The decision to "put the deadline 2 years back" was proposed in late 2016 and approved unanimously soon after. Kind regards

Hello! Eddie is late in development, for a combination of adverse causes which we are going to list here below. On the server side, OpenVPN has been properly patched and tested. Some parts of code have been rewritten properly to provide a real IPv6 full support (task completed successfully by berserker). @NaDre: currently micro-routing in IPv6 is not fully implemented. It will probably come later. Eddie is late mainly because: the ISP lines supporting IPv6 which are available to our developers malfunction often. IPv6 goes down frequently. Only in December, the devs reported an IPv6 black out of several days without interruption! Such events force the developers to perform any test remotely, between servers in which IPv6 works properly, and the consequence is a delay in development (one thing is testing from your office and house directly with IPv6, one thing is testing remotely via IPv4 connections controlling remotely IPv6 supporting machines in which you run any new Eddie alpha version). This is a dramatic infrastructural/ISP configuration problem in Italy which we have no control on, of course. We can't even rely on multiple ISPs because a pure IPv6 support is currently not provided by most of italian ISPs.we have had a nasty problem which causes a malfunction with usage of IPv6 (in the VPN) from an IPv4 only line. This problem is "nasty" because it occurs only on Windows 7, 8, 10, while on OS X, macOS and GNU/Linux Eddie works just fine with the very same pieces of code. As a consequence, troubleshooting this issue has been time consuming - we want to publish an Eddie version which works on all supported platforms, we don't want to leave Windows behind for obvious reasonsKind regards

Hello, Under Windows, this critical error might be caused by a possible bug in OpenVPN triggered when the log file is large, can you please check? Also compare with: https://community.openvpn.net/openvpn/ticket/454 Strange that it comes out with Eddie, though, because it is reproducible only with OpenVPN Connect usage as far as we know. Maybe this is not the real cause, but it's worth a check anyway. Kind regards

THIS THREAD IS NOW OBSOLETE - PLEASE JUMP HERE: https://airvpn.org/topic/25148-ipv6-support-experimental-phase/ Hello! We regret to inform you that IPv6 full support has been delayed. Here is the current, new roadmap for IPv6 support deployment in our infrastructure: Within 15.Jan.18: - at least one public VPN server supporting IPv6 - release of new Eddie version which fully supports IPv6 routing and any other necessary function If no problems arise, or when unexpected problems are resolved, deployment of IPv6 on all the other VPN servers which are in an IPv6 capable network (i.e. the overwhelming majority in our infrastructure - only 2% of the servers will not support IPv6 due to technical limitations of the datacenter they are in). Such a wide scale deployment will be very fast (a matter of a day or two a few days). We apologize for the inconvenience. We are well aware that full IPv6 support for the end of December 2017 had been planned since 2016 and we'll do our best to minimize the delay. Kind regards and datalove AirVPN Staff

The whole range of IP addresses of the dc where GB2 is in is already blocked. We operate in 4 additional datacenters in the UK and we tested other IP ranges in additional datacenters, we don't even remember anymore how many. All of such ranges are blocked. It is more efficient for BBC (or Netflix or anybody else interested in discriminatory accesses) to just black list those IP addresses which stream concurrently more than x streams (the value can be accurately calculated to not affect customers behind a NAT of a residential ISP) while a white list of IPv4 addresses assigned to UK (or any other country) is compiled, which is another very effective solution for all the happy scullions of the copyright industry (except when they wonder how it's possible that file sharing increases instead of going down during time with the new streaming services) or just to contribute to build walled gardens for the fools. It's not the main purpose of our service, but just a nice side effect, which will probably work less and less in the future. It would be very risky to hope to cover the expenses of our infrastructure with a geo-restriction bypass service, and we never really counted on it. In 2014 or 2013 we advertised this side-effect for a few days in the home page, and we quickly stopped because we saw it as a mistake with no future (it looks like we were right, unfortunately). However, as you could read before in this answer, this does not mean that we don't care about you: we have employed time and resources to make BBC accessible. Kind regards