Staff

@giganerd Hello! What happens if you don't specify "-6 no"? And with "-6 yes"? And with no "-6" at all? Omitting "-6" is not equivalent to "-6 no" or "-6 yes" apparently ("apparently" because it is undocumented) so it's worth to test all 3 options. We have fixed several bugs from the main branch and if necessary we will start investigating this one too. So, first and foremost, let's ascertain that this is a bug for real. Here what you can infer from the source code comments: // IPv6 preference // no -- disable IPv6, so tunnel will be IPv4-only // yes -- request combined IPv4/IPv6 tunnel // default (or empty string) -- leave decision to server std::string ipv6; [You might ask why we don't do it ourselves, the problem now is that all developers lines and all testing servers have either IPv6 down or no IPv6 at all] Kind regards

@Dramanaught Thanks a lot! No overselling has always been our workhorse, we were the first to publish a real time servers monitor as an element showing no overselling. Load balancing inside single VPN servers came later in 2017 (general load balancing at infrastructure level was built in 2011 and improved in 2012 and 2013). About the load balancing at server level: since OpenVPN runs in a single core and does not scale, we decided to run one or two OpenVPN daemon(s) per each core, and send each new client connection to the OpenVPN daemon running in the least loaded core (according of course to the picked connection mode). As far as we know no other VPN service (based on OpenVPN) does the same. The outcome has been interesting because we can now squeeze up to 1.7 Gbit/s on AES-NI machines with 4 cores Xeon CPUs, which should be a record for OpenVPN servers on equal terms (CPUs etc.). Kind regards

Hello! We're very glad to inform you that: a macOS beta version is now available Linux 64 bit and Raspbian beta versions are now available (we recommend that you upgrade from the previous alpha versions) OpenVPN library has been updated to version OpenVPN AirVPN 3.6.1 The initial message with download links and instructions has been updated accordingly. Kind regards

Hello! We are glad to inform you that we have released a new version of OpenVPN-AirVPN library which is essential to our imminent release of a client for macOS which will be added to the clients for Linux 64 bit and Raspbian: https://github.com/AirVPN/openvpn3-airvpn/blob/master/CHANGELOG.txt Kind regards AirVPN Staff Changelog 3.6.1 AirVPN - Release date: 28 November 2019 by ProMIND - [ProMIND] [2019/11/28] openvpn/tun/builder/base.hpp: Added virtual method ignore_dns_push() to TunBuilderBase class - [ProMIND] [2019/11/28] openvpn/tun/client/tunprop.hpp: added DNS push ignore to method add_dhcp_options() *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 3.3.2 AirVPN - Release date: 10 October 2019 by ProMIND - [ProMIND] [2019/09/04] fixed bug in openvpn/tun/linux/client/tunsetup.hpp: changed if(conf->txqueuelen) to if(conf->txqueuelen > 0) which made linux connection to fail - [ProMIND] [2019/09/04] openvpn/tun/linux/client/tuncli.hpp: added initialization to TunLinux::Config::txqueuelen - [ProMIND] [2019/09/10] openvpn/tun/linux/client/tunsetup.hpp: removed remove_cmds->execute(os) call in establish which prevented reconnection to work properly - [ProMIND] [2019/09/10] openvpn/tun/linux/client/tunsetup.hpp: removed connected_gw member and related code which prevented reconnection to work properly - [ProMIND] [1019/10/10] openvpn/client/cliopthelper.hpp: added method getRemoteList(). Returns remoteList member with list of profile's remote entries - [ProMIND] [2019/10/10] client/ovpncli.hpp: added RemoteEntry structure to reflect profile's remote entries - [ProMIND] [2019/10/10] client/ovpncli.hpp: added remoteList member - [ProMIND] [2019/10/10] client/ovpncli.cpp: OpenVPNClient::parse_config now assigns remoteList member with values of ParseClientConfig.getRemoteList() *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 3.3.1 AirVPN - Release date: 31 August 2019 by ProMIND - [ProMIND] [2019/08/06] Added cipher override to client configuration - [ProMIND] [2019/08/06] Added ncp disable override to client configuration *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 3.3 AirVPN - Release date: 13 July 2019 by ProMIND - [ProMIND] [2019/06/02] Forked master openvpn3 repository 3.2 (qa:d87f5bbc04) - [ProMIND] [2019/06/06] Implemented CHACHA20-POLY1305 cipher for both control and data channels - [ProMIND] {2019/07/10] Implemented ncp-disable profile option

Hello, each VPN server runs its own DNS server https://airvpn.org/specs Kind regards

The simplest method is through WebRTC or any other STUN based technique, which will reveal your private addresses (or more precisely the IP addresses of your interfaces, virtual or real) even with Network Lock enabled (it will NOT reveal your public IP address, of course). Check in ipleak.net for example. Kind regards

@SurprisedItWorks tls-crypt will encrypt the whole OpenVPN Control Channel since the very beginning, tls-auth will not. tls-crypt and tls-auth are mutually exclusive. tls-auth is offere on VPN servers entry-IP addresses 1 and 2, tls-crypt on VPN servers entry-IP addresses 3 and 4. tls-crypt is particularly good at bypassing different block types agains OpenVPN. If combined with TCP and port 443, it is quite effective against most blocking techniques targeting OpenVPN and/or UDP. Kind regards

@rndbit In Wireguard you need to map a static IP address in the VPN to a client key permanently as dynamic IP assignment is not available. The private IP address is easily found out by anyone. Once we receive a request by a proper authority about the VPN IP address we can link the address to a unique account. That's a serious privacy concern that does not exist in OpenVPN. Now that we have ChaCha20 cipher even in OpenVPN Data Channel (including our OpenVPN 3 library), there's no pressure to push our customers toward dangerous solutions just for marketing reasons. We can quietly wait for a Wireguard's stable release featuring all the implementations we need (dynamic IP addresses and TCP support). Kind regards

Hello! We can't, it's a not enforceable clause. Kind regards

Even if the attacking adversary would not need to catch your DNS queries they still can catch your dns traffic if they could, employees/insiders who work for the company could maliciously collect if they wanted to. That’s why having a secure dns that goes though the vpn infrastructure is an added security. Partition of trust still has a flaw that could be improved, the final vpn tunnel will still send your dns queries unencrypted. Just because a vpn company states they don’t log users data it doesn’t mean someone on the inside covertly could. Hello! Let's fix some very bad misconceptions. 1. That's false, the attacking adversary can not catch your DNS queries when tunneled into the VPN, unless he/she is inside your machine with administrator privileges, in which case of course neither DNSCrypt nor VPN nor Tor can defend you. 2. Incorrect. When you connect Tor over OpenVPN: the final VPN server sends everything encrypted to Tor entry-node VPN server can not even discern the type of traffic, because the whole payload is still encrypted by Tor, DNS queries included your ISP or network administrators will not see that you're using Tor because its traffic is still wrapped into OpenVPN TCP or UDP tunnel. DNS queries are inside Tor tunnel which is inside OpenVPN tunnel Tor can not see your real IP address Tor circuit is renewed at each new TCP stream a malicious datacenter or a rogue VPN company will see nothing of your traffic content, as it's encrypted traffic unreadable to them (that's why some rogue VPNs blocked Tor traffic, they can't mine your data) Kind regards

@pizza Hello! We agree with you, it would have been nice but not at the price to lower our standards. The reasons of our fork have been already explained here: https://airvpn.org/forums/topic/43850-openvpn-3-development/?do=findComment&comment=98527 Kind regards

Hello! Can you please test again now (restart the connection)? Kind regards

Hello! We're very glad to inform you that the Black Friday week has just begun in AirVPN! Save up to 74% when compared to one month plan price Check all plans and discounts here: https://airvpn.org/plans If you're already our customer and you wish to jump aboard for a longer period, any additional subscription will be added on top of already existing subscriptions and you will not lose any day. And that's not all: AirVPN offers five simultaneous connections per account, IPv6 full support, AES-GCM and ChaCha20 encryption ciphers and even more, exclusive features: https://airvpn.org/topic/28153-ipv6-support-and-new-smart-features/ AirVPN is the only VPN provider which is actively developing OpenVPN 3 library with key features: https://airvpn.org/forums/topic/44069-openvpn-3-development-by-airvpn/ Any doubt or question? Please check the following, awesome guide first: https://airvpn.org/forums/topic/45694-airvpn-sales-things-to-know/

Hello and thank you for your nice feedback! As far as we can see from the log, various delays sum up. During the connection a delay is caused by OpenVPN when it calls "netsh.exe" and "route.exe" the first time. After both binaries have been called for the first time, subsequent calls become faster (caching). It hints to some slow I/O (more on this later). First, try to resolve the following warning: W 2019.11.24 21:42:24 - OpenVPN > Warning: route gateway is ambiguous: 192.168.1.1 (2 matches) It is generally caused by two interfaces having the same gateway, for example if you keep Ethernet and WiFi connections to the same router both active. You can in this case turn off WiFi card, if it's not needed by some other setup in your system. As far as it pertains to Eddie, we see delays in the DNS flush (5 seconds), which is a highly recommended procedure, so nothing effective can be done about it. Another 5 seconds delay is caused by route check and DNS check, security operations which can be suppressed if you keep Network Lock enabled. You can bypass them respectively: - in "Preferences" > "Advanced", by unticking "Check if VPN tunnel works" - in "Preferences" > "DNS" by unticking "Check Air VPN DNS" Remember that if you cancel the above verifications, you should keep Network Lock enabled for safety reasons. A high delay is caused by Eddie's DNS operations: . 2019.11.24 21:42:28 - DNS leak protection with packet filtering enabled. . 2019.11.24 21:43:52 - DNS IPv4 of a network adapter forced (Ethernet 2, from automatic to 10.6.14.1) . 2019.11.24 21:43:52 - DNS IPv6 of a network adapter forced (Ethernet 2, from automatic to fde6:7a:7d20:20e::1) You can see that between "leak protection with packet filtering enabled" and forcing DNS on network adapters the remarkable amount of 24 seconds is needed, which is unexpected, as in our systems Eddie is much faster to do that. Please check whether your HDD is significantly fragmented. If it is, consider to defragment it: all operations involving I/O to/from the HDD will be faster after the procedure is complete, including I/O by OpenVPN and Eddie. Last but not least, Eddie 2.18.5 beta has been rewritten in various parts to speed up various operations. If you wish so, you might test the latest Eddie and check whether connection time decreases. If you are interested in testing, please see here: Feel free to keep us posted! Kind regards

Hello! Thank you for your public and private bug reports and for you ongoing support. About your questions: We confirm: OpenBSD and FreeBSD versions are planned. However, they will probably not be available before Christmas, we're terribly sorry. Currently, OpenVPN 3 can not be compiled in *BSD, therefore some additional work is required. Yes, pf for Network Lock will be supported in Mac, FreeBSD and OpenBSD. ipfw support is under evaluation. More on plans about a GUI will be released in the future. A study about asio and socket buffers is not yet complete. At this early stage it seems that OpenVPN 3 does not need fixed buffer sizes and asio seems capable to fine tune buffers properly, according to various speed tests and comparisons. Please keep in mind once again that the issue you raised is still in early stage investigation. Kind regards

Hello! Unfortunately not, because under the scenario you describe the attacking adversary would not need to catch your DNS queries to see your traffic destinations and origin. You can defeat the adversary anyway with "partition of trust", for example by connecting to Tor after you have connected to the VPN. Kind regards

@giganerd Things evolve and we always have replacements ready. In the USA the situation is extremely peculiar because the climate is hostile and it's hard to find datacenters which work well AND do not fear many notices on alleged copyright infringements for example. With the last replacement you mention, note that we have added a new provider. Also note that our relation with Leaseweb, after a harsh divorce, is again very good. In Germany we have many servers with Leaseweb DE, in Singapore we have three servers with Leaseweb SG. If you compare situation with that of one and a half year ago, we don't have less providers now. Kind regards

Hello! While we will let developers provide more details should they wish so, we would like to firmly clarify that: Eddie 2.18.x GUI or command line frontend does not run as root; the backend process does Eddie 2.18.x is in beta testing phase, so potential bugs and issues should be in general expected at any time Eddie 2.18.x does not run "curl" with root privileges anymore @QueenSasha Eddie 2.18.x GUI is written in C# (so it needs the Mono framework) but the backend process is written in C++, so it does NOT need Mono framework. Running only a GUI in Mono with normal user privileges shrinks down Mono related risks very considerably @inradius If you find critical Mono vulnerabilities even related to apps running with user privileges things would be different, of course root privileges are necessary to modify firewall rules (for "Network Lock"), change routing table, properly handle DNS push. Root privileges are also transmitted to OpenVPN, which needs them to modify routing table, default gateway and operate on tun network interface. That's expected, correct and ordinary behavior by any OpenVPN based software developer @inradius unless you have a special API service, as it happens in Android with VPNService API, where root privileges are not needed (and you can't set a real "Network Lock" as a consequence) if any security vulnerability is ascertained and proven we and developers will of course address it expeditiously @QueenSasha Kind regards

Hello and thank you for your choice! Can you please send us a system report generated by Eddie, the Air client software, and taken just after the problem has occurred? Please click "Logs" tab, click the LIFE BELT icon, click "Copy to clipboard" and paste into your message. Kind regards

@dedo299 Hello and thank you for your considerations! We will evaluate them carefully. Currently we just want to underline that Heze and Persei suffered too many partial and total outages for our standards and the frequent events caused quite a remarkable amount of complaints, and rightly so, by our customers. Keeping those servers in spite of the collected evidence and feedback would have been detrimental for the quality of our service as it's bad to have a well performing server when the datacenter, for various reasons that have been occurring again and again, can't ensure anymore a decent uptime. We also wish to specify that Aquila, the server you mention giving you good performance, which is from a different provider, remains in Fremont: it is not one of the soon to be dismissed servers. Kind regards

Or not: it depends on whether they are tunneled. In Linux based systems with global DNS (i.e. without on-link DNS simulation) DNS queries to any public DNS will be tunneled. In Windows there is no global DNS concept so such queries in general will not be tunneled. That's also the reason why DNS leaks don't exist in Linux, unless it's deliberately configured to emulate rickety broken DNS implementation, but they are common in Windows and patched client-side by OpenVPN based software. As a side note fir the OP: remember that DNS settings on the devices behind the router will determine the finala ddress to send queries to. Only if they query the router address in the local network, then the DNS servers set on the router will be queried. If they query any other DNS, their DNS queries will be anyway tunneled by Tomato router (and our VPN servers will then send them to the final destination, get the reply, and send the reply to you). About the original problem experience by OP: OpenVPN server pushes IPv6 routes even when the client does not explicitly require them. Together with the fact that if "ip" (or any similar command) fails with IPv4, even if it's successful with IPv4, OpenVPN quits immediately, you can understand how gross and questionable this behavior is: any client without machine IPv6 support will be unable to connect. So, we will force OpenVPN to NOT push IPv6 routes, unless IPv6 is explicitly required. The patch has been implemented and deeply tested, it is safe and compact, and will be deployed in all servers progressively but swiftly. Currently only 40 servers still pose the problem caused by the "original OpenVPN behavior". Remember that the problem affects only systems which lack IPv6 support (they don't exist anymore but someone might disable IPv6 at system level for any reason, or use very old systems, so we are working to fix the issue quickly in the whole infrastructure). To get OpenVPN IPv6 push you will need necessarily the following directives: push-peer-info setenv UV_IPV6 yes The Configuration Generator already works accordingly and adds the proper directives if you require IPv6 over IPv4. Kind regards

@dedo299 Hello! We have picked a datecenter in Los Angeles to replace two Fremont servers (quite near in terms of network distance and very near geographically). The new LA servers announcement, where we specified that they replaced servers in Fremont, is here: Kind regards

Hello! We inform you that the following servers will be dismissed on November the 26th as they do not meet anymore our quality requirements in terms of line reliability and datacenter support. Alkaid Heze Microscopium Pavonis Persei The aforementioned servers have already been replaced by other servers in the same locations, running in datacenters which are currently offering higher reliability. You can check the servers status and additional information on our servers monitor here: https://airvpn.org/status Kind regards AirVPN Staff

@Flx Hello, just a note: 10.5.0.1 is no more used since a long ago. VPN DNS server primary address matches VPN server gateway, secondary address is 10.4.0.1 (regardless of the subnet you are in). 10.4.0.1 is not reachable by ping, but only DNS queries. https://airvpn.org/specs Kind regards

We would like to do so but our resources are limited and selections and choices must be made. Kind regards