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

Hello! We're very glad to inform you that two new 1 Gbit/s servers located in Vancouver (Canada) are available: Nahn and Sham. The AirVPN client will show automatically the new servers; if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). Servers accept connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other "second generation" Air server, Nahn and Sham support OpenVPN over SSL and OpenVPN over SSH, TLS 1.2 and tls-crypt. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check servers status in our real time servers monitor: https://airvpn.org/servers/Nahn https://airvpn.org/servers/Sham Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! We're glad to inform you all that Chamaeleon https://airvpn.org/servers/Chamaeleon in Dallas now runs OpenVPN 2.5 daemons and is configured to accept connections with cipher CHACHA20-POLY1305 both on Control and Data Channel. You can connect in ChaCha20 with Eddie Android edition, OpenVPN 3.3 AirVPN alpha for Linux, or by using Eddie desktop edition with OpenVPN 2.5. To use cipher ChaCha20: with Eddie Android edition, select "Settings" > "AirVPN" > "Encryption Algorithm" > "CHACHA20-POLY1305" with OpenVPN 3.3 AirVPN please see here: with Eddie desktop edition, install OpenVPN 2.5, tell Eddie to use OpenVPN 2.5 in "Preferences" > "Advanced" , finally add the following custom directives in "Preferences" > "OVPN Directives" and make sure to connect or white list ONLY experimental ChaCha20 servers ncp-disable cipher CHACHA20-POLY1305 Servers supporting ChaCha20 are marked as "Experimental ChaCha20" in https://airvpn.org/status in a yellow warning. Kind regards

Hello! We're very glad to inform you that three new 1 Gbit/s servers located in Chicago (Illinois, USA) are available: Fang, Kruger and Sneden. Note that the aforementioned servers replace Alkaid, Microscopium and Pavonis which do not meet anymore our technical requirements in terms of uptime and line reliability and will be withdrawn at the end of November. AirVPN clients will automatically show new servers; if you use OpernVPN or some other OpenVPN frontend, you can generate all the files to access any server through our configuration/certificates/key generator (menu "Client Area" -> "Config generator"). Servers accept connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like all the other AirVPN servers do, Fang, Kruger and Sneden support OpenVPN over SSL and OpenVPN over SSH, TLS 1.2 and tls-crypt. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols, smart load balancing between OpenVPN daemons and hardened security against various attacks with separate entry and exit-IP addresses. You can check servers status as usual in our real time servers monitor: https://airvpn.org/servers/Fang https://airvpn.org/servers/Kruger https://airvpn.org/servers/Sneden Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! We're very glad to inform you that two new 1 Gbit/s servers located in Los Angeles (California, USA) are available: Groombridge and Teegarden. Note that Groombridge and Teegarden replace Heze and Persei which do not meet anymore our technical requirements in terms of uptime and line reliability and will be withdrawn at the end of November. AirVPN clients will automatically show new servers; if you use OpernVPN or some other OpenVPN frontend, you can generate all the files to access Groombridge and Teegarden through our configuration/certificates/key generator (menu "Client Area" -> "Config generator"). Servers accept connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like all the other AirVPN servers do, Groombridge and Teegarden support OpenVPN over SSL and OpenVPN over SSH, TLS 1.2 and tls-crypt. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols, smart load balancing between OpenVPN daemons and hardened security against various attacks with separate entry and exit-IP addresses. You can check servers status as usual in our real time servers monitor: https://airvpn.org/servers/Groombridge https://airvpn.org/servers/Teegarden Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! We don't, and anyway even if some service of ours listened to that port of our VPN servers exit-IP address, we would of course not forward packets to VPN nodes (!), if the customer did not require such thing. In this case that's what you did (you remotely forwarded inbound port 12103) so what you see is perfectly normal. Kind regards

Hello! Currently Netflix USA (and only USA) is accessible from our infrastructure, including UK servers, provided that you query VPN DNS. Kind regards

Hello! Stay tuned, we have planned to add one or two servers in Vancouver. Kind regards

@Gebi22 Hello! Please make sure that you have not defined specific filters that filter out all the servers. If the above is not the case, please open a ticket and include Eddie log taken just after the problem has occurred. In Eddie's "Log" view you can see a "Share" icon. After you have tapped it you can choose to send log via mail or share it in other ways. Kind regards

@Bubga Hello! Currently Netflix USA (and only USA) is accessible from our infrastructure, provided that you query VPN DNS. Kind regards

@giganerd Hello! Well, it's not uncommon that any source code is not released at alpha stage. In several environments it is common practice. It is all in all a wise decision because any part can be even rebuilt from scratch, even from alpha n to alpha n+1. However, as you noticed, the library source code is published and of course it's not alpha.  That would be great! Kind regards

@pjnsmb After you press CTRL-C resolv.conf backup is correctly deleted so the reply you get after you ordered "--recover-network" is expected. Up to this point everything sounds fine. Then you notice lack of Internet connectivity, which might or might not be expected. Please check firewall rules as well as chain policies before and after the VPN connection: if they match your lack of Internet connectivity is expected; if not something wrong is going on, please notify us including rules (first and after you have run the client) and exact distribution name and version. Kind regards

Hello! -6 is an undocumented option in OpenVPN 3 library, it has nothing to do with the frontend. OpenVPN 3 is mostly undocumented by OpenVPN developers and we are doing our best to fill the gap. In the next version we will clarify usage of -6 option to leave no doubts on the matter. You can infer that -6 pertains to IPv6 over IPv4 from the comments in the source code, which contrarily to what your misleading irony suggests has been published in GitHub a long ago. https://github.com/AirVPN/openvpn3-airvpn Anyway that part is identical to the main branch and has not been touched by us, so you can see that part both in our fork and in the main branch, it exists since years ago and has remained undocumented since years ago. At this stage we are focused on bug fixing because, for Linux, we found a dramatic situation to say the least. just consider, as a mere, shameful example, that data structures were systematically not initialized, an error that you can't expect or imagine, not even from C novice children students during their first C course. Lack of initialization in C/C++ causes apparently random crashes and/or unexpected behavior in different conditions, systems and system states, according to how "dirty" the data RAM area is or is not. Situation is now under control (while OpenVPN 3 main branch remains mainly unusable in Linux for practical purposes) but only after a very hard, time consuming work. That said, omitting -6 might not solve the issue. We suspect now that it's another OpenVPN 3 bug; as such we will investigate with the purpose to fix it. Please test anyway without -6 option and let us know the outcome at your convenience. (DONE) Kind regards

@giganerd Hello! We might be in presence of a conflict when you try an IPv6 connection and at the same time you also want IPv6 over IPv4 (which actually may appear contradictory). The error pertaining to address parsing comes from OpenVPN 3 library. Can you tell us whether the problem is resolved or not when you don't force IPv6 over IPv4 for an IPv6 connection (i.e. do not include -6 option)? Kind regards

@pjnsmb Hello! We're not yet in beta testing (EDIT: since Nov 29 we are ), thanks for the trust, but we count to release a beta version soon (for Mac too). Can you tell us your exact Linux distribution name and version and send us the client log taken just after the problem has occurred? Using the screen utility was a suggestion pertaining to a different case, or maybe are you connecting remotely via ssh or telnet to the machine that will connect to the VPN? If so using screen is absolutely not a hard work, it's piece of cake don't worry. Kind regards

Hello! AirVPN OpenVPN 3 client version 1.0 alpha 2 is now available. It addresses reported bugs and should resolve them. AirVPN OpenVPN 3 Client 1.0 alpha 2 - 7 November 2019 Changelog [ProMIND] DNS resolver has now a better management of IPv6 domains [ProMIND] DNS resolver has now a better management of multi IP domains [ProMIND] Minor bug fixes ======== Linux 64 bit build can be downloaded here: https://eddie.website/repository/eddie/airvpn-static1.0alpha/airvpn-static-linux-1.0-alpha2.tar.gz SHA512: https://eddie.website/repository/eddie/airvpn-static1.0alpha/airvpn-static-linux-1.0-alpha2.tar.gz.sha512 Linux Raspbian 32 bit build can be downloaded here: https://eddie.website/repository/eddie/airvpn-static1.0alpha/airvpn-static-raspberry-1.0-alpha2.tar.gz SHA 512: https://eddie.website/repository/eddie/airvpn-static1.0alpha/airvpn-static-raspberry-1.0-alpha2.tar.gz.sha512 Thank you for your tests! Kind regards

@WindUp Hello! Agreed. Since when we decided to cut any intermediary for cryptocurrencies payments, we need to implement crypto payment options one by one internally. Monero is the next on list anyway. Kind regards

@maxandjim Thank you, we will investigate about communications in the local network. If for some reason the remote ssh session gets broken with CTRL-C you can consider to run the client inside a screen and send a soft kill signal when you want to shut it down gracefully. Warning: if you lose ssh connection, the client will continue to run in "its screen", completely detached (even its stdin, stdout and stderr will be detached from the previous shell) so the machine will remain connected to the VPN and "network locked": make sure you can remotely force a machine reboot as an emergency rescue just in case you can't access it anymore via ssh. About fantastic screen utility: https://www.gnu.org/software/screen Kind regards

Hello! Of course you are correct. We plan to release the stable edition of the software (or maybe the beta version) on GPLv3. We are at alpha stage currently, as you may have noticed. However OpenVPN 3 AirVPN code is available, have you examined it? Here it is: https://github.com/AirVPN/openvpn3-airvpn Kind regards

Thanks a lot! Bug confirmed, a fix will be available soon. Kind regards

Hello! No problems detected at the moment... Do you still experience the issue? If so, does it persist if you log your account out and in again? Kind regards

Hello! ovpn profiles are not scripts or binaries that you can run: they are text files that will be parsed by some OpenVPN binary. Use profiles as arguments of the client software as you always did. Let's end it here and now, please: if you need clarifications on that, please feel free to open a ticket at your convenience because it's off topic here. Kind regards

Hello! @giganerd Bug detected and fixed, a new testing version is almost ready to be deployed. Thanks! @QueenSasha Thank you, actually speed, efficiency and low RAM footprint have been a priority in OpenVPN 3.3 AirVPN design. Glad to hear that you get remarkable performance boost in Raspberry. Our OpenVPN 3 development goes on and is aimed as usual to bug fixing and new features implementation. Developer will answer soon to your technical questions, in the meantime feel free to keep us posted if you find any glitch or bug. @usr32 Great comparison thank you! We are surprised that you could beat AES with ChaCha20 in an AES-NI supporting machine. Can you please specify the whole architecture? We would like to make some verifications with OpenVPN 3+mbedTLS for AES-NI support in specific archs. @GJElde So you made an OpenVPN text configuration file +x and you tried to run it? @maxandjim Thank you, we will investigate asap. Kind regards

Hello! If you have time to make comparisons, please take note whether OpenVPN 2, on rigorously equal terms (therefore no ChaCha20 comparison is possible unless you run OpenVPN 2.5 beta), is faster or slower than 3.3, and feel free to publish the throughput you get with both versions. Kind regards