Staff

Hello! Old ca.crt certificates signed with SHA1 are no more used: the change occurred a lot of time ago, Furthermore, SHA512 is now the new default "setting" for your client certificate. You can handle your client certificate and key from your account "Client Area", please see here: https://airvpn.org/topic/26209-how-to-manage-client-certificatekey-pairs/ If you refer to OpenVPN channels, SHA1 has never been used (and not usable in OpenVPN). The authentication cipher is HMAC or, if you use an AED-ready cipher with latest OpenvPN versions (AES-256-GCM in our service), the authentication of the packets is performed by the AES cipher itself. Even if you use old OpenVPN versions which rely on HMAC SHA1 and/or do not support HMAC SHA384 and/or AES-GCM, you are perfectly safe (do not confuse HMAC SHA1 with SHA1). The math proof for this claim and additional information are reported here: https://airvpn.org/topic/21914-encryption-algorithm-solved/?do=findComment&comment=58238 Kind regards

Hello! We're very glad to announce that a brand new Eddie Android edition has been released. Please see here: https://airvpn.org/topic/26549-eddie-android-edition Kind regards and datalove AirVPN Staff

Hello! We're very glad to inform you that a new version of Eddie for Android has been released. The application ID is now org.airvpn.eddie and the released version is 1.0 beta (UPDATE 21-Sep-18: Release Candidate 5 is now available, please see https://airvpn.org/topic/26549-eddie-android-edition/page-7?do=findComment&comment=77774 ). This release replaces the previous one completely and we recommend that you switch to it. As usual Eddie is free and open source software released under GPLv3. You can participate to the beta testing by joining the beta community in the Google Play Store here https://play.google.com/apps/testing/org.airvpn.eddie Alternatively, if you don't want to access (or you have no access to) the Google Play Store, the apk ill be available soon in our web site. We aim to speed up the release cycle from now on and we confirm that Eddie will be more and more integrated with AirVPN with the progressive implementation of several functions and options that you can find in Eddie for other platforms. In addition to ARM64 support, various bug fixes, improvements and changes have been applied, including changes aimed to make Eddie more consistent with Android design best practices. For a detailed list, please see below the attached changelog. The project has been assigned to a new developer (you can see a credit mention in the changelog) under the supervision and verification, as usual, of Eddie lead programmer Clodo. Please feel free to write in this thread about this new release, what you like and what you hate, and of course any detected bug. Kind regards and datalove AirVPN Staff ChangeLog.txt

Hello! Why should we do that? In other words, what advantages in terms of security and/or performance do a user get from Wireguard (over OpenVPN) when deployed before an audit has been performed? In terms of performance, we are concerned about this: https://www.wireguard.com/performance/ The Wireguard performance is low, while the OpenVPN reported throughput is fake. Remember that we could beat in a single core of an archaic Q6600 CPU 300 Mbit/s in 2014. In 2018 (just a couple of weeks ago) we have obtained 1.7 Gbit/s on our AES-NI optimized machine with a load of 300+ clients practically in just ONE CORE of an E3-1270 @ 3.80 Ghz with a Linux kernel 4.9 and AES-256-GCM (so we could even go higher with ChaCha20 Poly305). The fact that in the Wireguard web site not believable data for OpenVPN is published is a reason of concern. Then, the performance of Wireguard is not interesting, especially on a core of an i7 with ChaCha20. On top of that, it is unfair to deploy to our customers a service based on a software that's not yet been tested enough in our opinion. USA Senator Wyden recently recommended Wireguard to replace everything (IPsec, OpenVPN...) in USA infrastructures and recommended to recommend Wireguard to NIST: https://www.phoronix.com/scan.php?page=news_item&px=WireGuard-Senator-Recommends Why this requirement before any serious audit when we know for sure (from the Snowden documents) that plans to insert backdoors in random number generators and other cryptography-related software, and then have that very software approved by NIST, started several years ago? This is another reason of concern that maybe makes Wireguard wide deployment premature: it is safer to check deeply the software and the ECC employed first, and then deploy to the public. Remember what happened with the infamous Dual_EC_DRBG, we are not short on memory like some of our competitors are, and we are not trading your security for a fistful of dollars by riding the Wireguard hype. When and if Wireguard will prove to be as secure as OpenVPN, and capable to provide the same (or higher) performance, and provide obfuscation and more protocols choice, then we'll be very happy to experiment with it. https://en.wikipedia.org/wiki/Dual_EC_DRBG#Software_and_hardware_which_contained_the_possible_backdoor Kind regards

Hello, we operate in two datacenters in Sweden (Uppsala and Stockholm) with totally different transit providers. In some cases those who have a good peering with one do not have a good peering with the other. In some cases peering is good with them both. Have you tested them both? If you get the same low performance in both you are served by an ISP which does not have good peering with both, in which case test a different country (at the moment we are good with two datacenters in Sweden). Kind regards

Hello! The guide had been updated some time ago to reflect the changes which have been implemented on "Generation 2" servers. Please consult it to modify your Comodo settings accordingly (probably only one change is necessary, you need to enlarge the authorized private addresses of the VPN network zone to the whole range 10.0.0.0/8). Please see here for the reasons of this change: https://airvpn.org/topic/28494-tunnel-private-subnet-changed/?do=findComment&comment=75305 You can find the announcement about Gen 2 servers here: https://airvpn.org/topic/28153-ipv6-support-and-new-smart-features/ Kind regards

Hello, with default settings Eddie prevents DNS leaks through Windows Filtering Platform. The method is the same than that implemented by the "block-outside-dns" directive of OpenVPN. Additionally Eddie lowers the tun/tap interface metric to solve the flawed Windows 10 DNS handling (made even worse by the "Creator" update). Have you modified the default settings or maybe you're running some packet filtering tool which sets WFP rules? Kind regards

Hello! Try to restart Eddie with default settings, just in case the xml file is corrupt. While Eddie is not running please delete this file: C:\Users\Garry\AppData\Local\AirVPN\default.xml You will need administrator privileges to do that. When you re-run Eddie, it will create a brand new configuration file with default settings. Note that you will need to re-enter your credentials. Kind regards

Yes, the subnets are unique for each OpenVPN daemon. You can't overlap when you connect to different servers for multi-homing from the same machine, for example. However, you have several small subnets /24 on each server, one per daemon, and you can't say in advance which subnet your system will enter because of the load balancing system which "welcomes" the clients and "assigns" them to the OpenVPN daemon running in the less loaded core (at the moment of connection). The huge convenience of this implementation is that now we can break the previous throughput limits caused by the lack of "parallelization" of OpenVPN. The Moore's law is being infringed and we can't expect significantly more powerful CPus (at one core level) for a long time; in computing power advancements we will probably never experience again (at least in our life) the peaks of 1996-1998; it's time to fight the software bloat, but a fully scalable multi-core OpenVPN release is probably not coming out soon; therefore the load balancing we have implemented is an immediate break through. Kind regards

Hello! Yes, you're right. We provided the wrong information. 10.4.0.1 can be used as a DNS server from every subnet but does not reply to ICMP. Kind regards

Hello! 10.4.0.1 remains good for your purpose. It is ping-able from any subnet. EDIT: nope. It is a DNS server IP address which is reachable from any subnet. Kind regards

10.4.0.1 must be ping-able from any subnet, if you experience this issue there's something wrong either in the server or in your connection. For a preliminary check can you please tell us the server(s) you experience this problem on? Kind regards

Hi Nadre, not random, they are unique (and always the same) for each OpenVPN daemon of each server. You will not find the same subnets, either in IPv4 or IPv6, in two different AirVPN servers or even daemons (that's why Gen 2 are multi-homing friendly, which is a feature frequently requested by pfSense and other systems users since when we provide five simultaneous connection slots). Kind regards

@kaymio Our assigned ULAs are in fde6:7a:7d20::/48 which is inside the range officially reserved to ULA so we don't understand why a browser should discriminate against them in favor of a local IPv4 address... Kind regards

Hello! In Generation 2 subnets are smaller and unique to each server OpenVPN daemon. In this way multi-homing becomes much easier and any (unlikely) overlapping with your local subnet somewhere in 10.0.0.0/8 can immediately be resolved by changing server. In IPv6, our assigned ULAs are in fde6:7a:7d20::/48 - even here collisions with your local addresses are very unlikely. Kind regards

When the whole infrastructure supports it, sure. In the meantime, is there anything unclear in the first post of this thread, in the Eddie protocols menu and in the Configuration Generator? They seem to tell what you want. Kind regards

Hello! We inform you that we have received the following warning from M24Seven, our provider for Prague servers and lines: network maintenance on our Prague PoP during the following time interval:. Start: 27th June 2018, 04:30 UTC End: 27th June 2018, 08:30 UTC During this time Infrastructure engineers will be working on upgrading the infrastructure serving Prague customers. Customers in Prague may experience sub-optimal routing, speed degradation and in some cases complete outage whilst the network is upgraded. These works are crucial to ensure additional services, resiliency and capacity out of this site. Since outages may not be ruled out, you might like to consider to avoid Prague servers during those four maintenance hours. Kind regards AirVPN Staff

Hello! The "Events" tab disappeared. This is a bug which will be fixed. Please downgrade to 2.13.6 in the meantime, if you need the "Events" menu. We apologize for the inconvenience. Kind regards

Hello! At the moment this is not planned, we're sorry. We want to maintain the protection you have with IPv4, where the exit-IPv4 address is shared between all the clients connected to a certain VPN, and the nodes are behind a NAT with a private address in some subnet. Kind regards

@serenacat Here the reports we have: China: tls-crypt always works in TCP and only sometimes in UDP (due to the fact that in mobile lines UDP is blocked by itself, we presume). OpenVPN over SSL works. tls-crypt is faster. Iran. same as China UAE: same as China Egypt: OpenVPN over SSL works. No reports about tls-crypt so far, unfortunately. Saudi Arabia: same as Egypt Kind regards

Just to clarify, does WebRTC show your public IPv6 address, your public IPv4 address or your private addresses? Kind regards I checked just now, and apparently its NOT any of my addresses. IPleak says its a "private use" one, its a 10.28.x.x address, which I think might be AirVPN?? Yes, as securvark explained as well, that's the virtual private network IP address. Therefore Network Lock works as expected and you have never had any leak. Everything was and is fine. Kind regards

Just to clarify, does WebRTC show your public IPv6 address, your public IPv4 address or your private addresses? Kind regards

Ok! We'll see to do something. Kind regards Quick question, are IPV6 addresses less likely to be blocked than their IPV4 counterparts? For example if a VPN IPV4 address is blocked and the offending network has IPV6 support, is a connection attempt through IPV6 instead possibly effective? Yes, it's possible. Yes, of course. Normally we have a /64 range per server, so... More info and details can be found here: https://airvpn.org/topic/28153-ipv6-support-and-new-smart-features/ Kind regards

Hello! Wait, while the other issues could be caused by the browsers and other factors we can't have any control on, this should NOT happen if Network Lock is enabled. Can you please try again with Network Lock enabled AND Eddie version 2.15.2? Kind regards

Hello! The sudden OpenVPN disconnection, which apparently occurs even before that OpenVPN tries anything to connect, makes us think about some problem with the tun/tap interface. In the past, it happened 3-4 times that OpenVPN did not work at all on Mac beta operating systems. Can you please increase log verbosity by ticking "Log debug" in the "Logging" window (then click "Save") and publish a system report, either here or in a ticket, taken just after the problem has occurred? Kind regards