Staff

@apero We confirm what we wrote in our initial message, we're sorry. @apero No doubts, but it's the system that's designed to prevent VPN connections at boot, and we loosely suspect that it's a deliberate choice. Remember that you have very limited control on "your" Android TV device, with limited privileges. We would be glad to implement some hack to allow connection at boot; so far we did not find any, unfortunately. Kind regards

UPDATE 2021-10-01: we have modified server side chain order. Therefore, even old TLS libraries bugs should not enter into play anymore. The quick fix is no more needed. Please feel free to report any malfunction. Hello! If you are running Eddie Desktop edition and you have started experiencing route check failures, read on. We have here a clear explanation, an easy solution and a slightly more complex solution as an alternative. Please make sure that you're running Eddie 2.19.7 or higher version (upgrade if necessary). The best solution is upgrading your TLS library and your curl and libcurl packages. However, if you can't or don't want to do so, a quicker and very simple workaround is available: from Eddie's main window select "Preferences" > "Advanced" de-tick "Check if the VPN tunnel works" click "Save" from Eddie's main window select "Preferences" > "DNS" de-tick "Check Air VPN DNS" click "Save" from Eddie's main window enable Network Lock The above quick fix will resolve the problem on Eddie. The initial checks become useless when you keep Network Lock enabled, so you don't have to worry about safety and security. We are considering whether packaging Eddie with proper curl and libcurl builds linked against very recent TLS libraries, but we must consider all the potential issues in each system. Explanation of the issue: consider that AirVPN uses mainly LetsEncrypt certificates. Then read here: https://blog.germancoding.com/2021/04/16/lets-encrypt-and-expired-root-certificates/ Now, if you run a cURL version linked against OpenSSL older than 1.1.0, or LibreSSL version older than 3.2.0, or GnuTLS version older than 3.6.7, the validation chain will fail (messed up path building) with the current LetsEncrypt certificates. It's a TLS library bug working in negative synergy with LetsEncrypt decision. Special thanks to Ryan Sleevi who made us understand exactly the nature of the problem with his great article written more than a year ago and which we read only now: https://medium.com/@sleevi_/path-building-vs-path-verifying-implementation-showdown-39a9272b2820 Kind regards

Hello and thank you for your choice! Please make sure that you're running Eddie 2.19.7 or higher version (upgrade if necessary). Then, please try the following settings: from Eddie's main window select "Preferences" > "Advanced" de-tick "Check if the VPN tunnel works" click "Save" from Eddie's main window select "Preferences" > "DNS" de-tick "Check Air VPN DNS" click "Save" from Eddie's main window enable Network Lock Try again connections to various servers. Explanation of the issue: consider that AirVPN uses mainly LetsEncrypt certificates. Then read here: https://blog.germancoding.com/2021/04/16/lets-encrypt-and-expired-root-certificates/ Now, if you run a cURL version linked against OpenSSL 1.1.0 or older versions, or against LibreSSL older than 3.2.0, or GnuTLS older than 3.6.7, the validation chain will fail (and Eddie does use libcurl and curl). It's a TLS library bug. At the moment we can not fix on our side: we would cut out all Android versions older than 7.1, and we don't want to do so . Momentarily, the above quick fix will resolve the problem on Eddie. The initial checks become useless when you keep Network Lock enabled, so you don't have to worry about safety and security. Kind regards

Hello and thank you for your choice! Please make sure that you're running Eddie 2.19.7 or higher version (upgrade if necessary). Then, please try the following settings: from Eddie's main window select "Preferences" > "Advanced" de-tick "Check if the VPN tunnel works" click "Save" from Eddie's main window select "Preferences" > "DNS" de-tick "Check Air VPN DNS" click "Save" from Eddie's main window enable Network Lock Try again connections to various servers. Explanation of the issue: consider that AirVPN uses mainly LetsEncrypt certificates. Then read here: https://blog.germancoding.com/2021/04/16/lets-encrypt-and-expired-root-certificates/ Now, if you run a cURL version linked against OpenSSL 1.1.0 or older versions, or against LibreSSL older than 3.2.0, or GnuTLS older than 3.6.7, the validation chain will fail (and Eddie does use libcurl and curl). It's a TLS library bug. At the moment we can not fix on our side: we would cut out all Android versions older than 7.1, and we don't want to do so . Momentarily, the above quick fix will resolve the problem on Eddie. The initial checks become useless when you keep Network Lock enabled, so you don't have to worry about safety and security. Kind regards

Hello and thank you for your choice! Please make sure that you're running Eddie 2.19.7 or higher version (upgrade if necessary). Then, please try the following settings: from Eddie's main window select "Preferences" > "Advanced" de-tick "Check if the VPN tunnel works" click "Save" from Eddie's main window select "Preferences" > "DNS" de-tick "Check Air VPN DNS" click "Save" from Eddie's main window enable Network Lock Try again connections to various servers. Explanation of the issue: consider that AirVPN uses mainly LetsEncrypt certificates. Then read here: https://blog.germancoding.com/2021/04/16/lets-encrypt-and-expired-root-certificates/ Now, if you run a cURL version linked against OpenSSL 1.1.0 or older versions, or against LibreSSL older than 3.2.0, or GnuTLS older than 3.6.7, the validation chain will fail (and Eddie does use libcurl and curl). It's a TLS library bug. At the moment we can not fix on our side: we would cut out all Android versions older than 7.1, and we don't want to do so . Momentarily, the above quick fix will resolve the problem on Eddie. The initial checks become useless when you keep Network Lock enabled, so you don't have to worry about safety and security. Kind regards

Hello and thank you for your choice! Please make sure that you're running Eddie 2.19.7 or higher version (upgrade if necessary). Then, please try the following settings: from Eddie's main window select "Preferences" > "Advanced" de-tick "Check if the VPN tunnel works" click "Save" from Eddie's main window select "Preferences" > "DNS" de-tick "Check Air VPN DNS" click "Save" from Eddie's main window enable Network Lock Try again connections to various servers. Explanation of the issue: consider that AirVPN uses mainly LetsEncrypt certificates. Then read here: https://blog.germancoding.com/2021/04/16/lets-encrypt-and-expired-root-certificates/ Now, if you run a cURL version linked against OpenSSL 1.1.0 or older versions, or against LibreSSL older than 3.2.0, or GnuTLS older than 3.6.7, the validation chain will fail (and Eddie does use libcurl and curl). It's a TLS ibrary bug. At the moment we can not fix on our side: we would cut out all Android versions older than 7.1, and we don't want to do so . Momentarily, the above quick fix will resolve the problem on Eddie. The initial checks become useless when you keep Network Lock enabled, so you don't have to worry about safety and security. Kind regards

Hello! Now we do not enforce any micro-routing to Binance, we have just re-checked and we have tested from Netherlands servers to confirm. Can you please re-check now? Kind regards

Hello! VPN DNS and "Assigned IP address" technical specifications just changed. All the changes have been reported in the https://airvpn.org/specs page. The changed section is: Assigned IP Servers support both IPv4 and IPv6 tunnels and are reachable over IPv4 and IPv6 on entry-IP addresses. DNS server address is the same as gateway, in both IPv4 and IPv6 layer. Chosen IPv4 Local Address OpenVPN: 10.{daemon}.*.*, Subnet-Mask: 255.255.255.0 WireGuard: 10.128.0.0/10 Chosen IPv6 Unique Local Address (ULA) OpenVPN: fde6:7a:7d20:{daemon}::/48 WireGuard: fd7d:76ee:e68f:a993::/64 The new sections are: DoH, DoT Every gateway/daemon assigned to you acts as a DNS (port 53), DoH (dns-over-http, port 443), DoT (dns-over-tls, port 853). DoH and DoT don't add any actual benefit, because plain DNS requests are encrypted inside our tunnel anyway. However, users might need it for special configurations. In such cases, use dns.airservers.org (automatically resolved into VPN gateway address). Our DNS returns a NXDOMAIN for "use-application-dns.net", for compatibility reasons. Special resolutions check.airservers.org - Gateway IPv4 and IPv6 addresses exit.airservers.org - Exit-IPv4 and exit-IPv6 addresses use-application-dns.net - NXDOMAIN, for DoH compatibility, ensuring Air DNS will be used (for anti-geolocation features) Special URLs https://check.airservers.org - Info about connected server https://check.airservers.org/api/ - Same as above, in JSON Use https://ipv4.airservers.org or https://ipv6.airservers.org - Same as above, specific IP layer Kind regards and datalove AirVPN Staff

Hello and thank you very much for your tests! This is no more a problem in Android 8 and higher versions. Do not turn VPN Lock on, but enable "Always on VPN" and its sub-option "Block traffic not in the VPN tunnel" in the Android settings. You will have complete leaks prevention and ability to re-connect, without leaks between disconnection and re-connection, in case of unexpected disconnection. We will investigate on the other bugs you found. We guess that you can't send us Eddie's log because in your system the "share" button crashes the app when tapped, right? What about a logcat, do you have the option to take it and send it to us after you have reproduced the various problems including the crash? https://www.siteforinfotech.com/capture-android-logs-minimal-adb-and-fastboot/ Kind regards

@airvpnforumuser Hello! We have failed so far to reproduce the problem you reported. Can you please tell us your device brand and model, and your exact Android version? You could also send us the first lines of Eddie log where thorough system information is printed. Thanks in advance! Kind regards

Yes, Google Search can index web sites even when the web server listens to non-standard ports, according to some Google executives. https://webmasters.stackexchange.com/questions/77378/does-google-treat-different-ports-as-different-sites https://webmasters.stackexchange.com/questions/61762/does-google-crawl-and-index-sites-hosted-on-an-ip-address-only-with-no-domain-n/61767#61767 Kind regards

@BKK20 Exactly. The port is always added as it is an integral part of the URI, but when omitted in the URI, this is auto-completed with :80 and :443 respectively for HTTP and HTTPS, as we already told you twice. AirVPN does not allow remote inbound port forwarding of ports between 1 and 2048, as reported in the FAQ and the manual. AirVPN is not a hosting provider. You might rent a VPS or a dedicated server to run your web server or any other service, and then you may make your service reachable on any port you like. If you don't need any privacy or anonymity layer for your web server (or other service), that's a logical solution, and it's not expensive. Kind regards

@BKK20 Step 1 is almost correct: please remember that our VPN servers have different entry and exit-IP addresses The relevant DNS record must be set to the exit-IP address. Step 2 is correct.. "after that" is not correct. The proper URI for your browser would be http://www.example.com:34567 or https://www.example.com:34567 (http or https according to your web server settings). Also remember to access your web server running behind a VPN server from a machine that's not connected to the same VPN server. Kind regards

@Stalinium Thank you! The problem has been resolved with the domain name. However, we still have issues with three servers in Dallas, including Pegasus, which have been closed (so they will not be picked for names resolution or by our software). We are working on them. EDIT: problem resolved. Kind regards

@JBronson Hello! The 1st problem was here: Sep 25 05:19:21 mostfantasticfox bluetit[2260]: Bluetit is already running or did not exit gracefully on its last run or has been killed. Exiting Sep 25 05:20:23 mostfantasticfox bluetit[2164]: Requested method "bluetit_status -> Bluetit is connected to VPN" Bluetit was in a dirty status and refused to proceed. However, when queried about the status it replied with the wrong message "connected to VPN". This is a bug we need to fix, thank you for having found it out, which explains why no tun interface was up when Bluetit misleadingly reported it was connected to the VPN. Later on, Bluetit does not detect anymore a dirty status but the nameserver remained set to a VPN DNS address, which is inaccessible from outside the VPN. Maybe you have tried to recover the network settings manually and you forgot to restore DNS? We ask because suddenly Bluetit does not detect anymore a dirty status and refuses to perform a network recovery: Sep 25 05:33:09 mostfantasticfox bluetit[1648]: Requested method "recover_network -> " Sep 25 05:33:09 mostfantasticfox bluetit[1648]: Requested method "Bluetit does not need a network recovery." Therefore, the subsequent connection attempts are doomed: Sep 25 05:28:21 mostfantasticfox bluetit[1441]: Allowing system DNS 10.7.58.1 to pass through the network filter Sep 25 05:28:31 mostfantasticfox bluetit[1441]: WARNING: Cannot resolve ca3.vpn.airdns.org (Temporary failure in name resolution) and Bluetit enters an infinite loop of re-connection attempts which don't succeed for the same reason. In order to resolve the issue, please make sure that Bluetit has exited cleanly and is not running, then manually modify DNS settings. Pick your favorite, publicly accessible, nameservers. Kind regards

Hello! Yes of course. Maybe you have missed the answers twice, please check them: https://airvpn.org/forums/topic/49776-own-webhosting-port-fowarding-set-a-record/?do=findComment&comment=169233 https://airvpn.org/forums/topic/49776-own-webhosting-port-fowarding-set-a-record/?do=findComment&comment=169282 Kind regards

Hello! 1. Thank you very much for your tests and bug report! We will check and fix. 2, Yes. Next version (either alpha 3 or beta 1, we'll see) will offer a range of options to start Eddie and have your device connected to AirVPN even without profiles, when the Master Password is disabled, during the bootstrap. Kind regards

@JBronson Hello! Can you please check your system DNS settings while Bluetit is not running and while it is running? ICMP packets for IP addresses outside the local network are correctly blocked by persistent Network Lock enforced by networklockpersist. An option to consider is that Bluetit fails the connection during the bootstrap. Although Bluetit answers to bluetit-stats with "Bluetit is connected to VPN", it is clearly belied by ifconfig output which does not show any tun interface in your system. Please make sure that VM kernel tun support is available, check Bluetit log and feel free to send it to us: sudo journalctl | grep bluetit Kind regards

Hello! We see remarkable, intermittent packet loss spikes every other hour or so on most Dallas servers. We are investigating. Kind regards

@cannac Hi! country is a directive you can include in bluetit.rc file to tell Bluetit where your node is, while the connection scheme file contains connection lists. The file is read by Bluetit to determine a connection list according to the country your node is in. DEFAULT is the connection list used by Bluetit when it does not know your country and a quick connection is required. Therefore DEFAULT -> US does not block connection to US servers whatsoever, while country xx will prevent connections to country xx (due to the famous "safety rule") when a quick connection is required and no white lists are specified. Check the syntax, there is no "=" symbol in the directive, just separate directives and their arguments with space(s) or tab(s). Kind regards

@cannac It would be the same thing, yes. DEFAULT is not restricted to two entries: you can list more areas (countries, continents, USA states...). Kind regards

Hi, you can, but it should work either way. Kind regards

@cannac In the meantime you can efficiently resolve the problem by editing the connection scheme in /etc/airvpn/connection_priority.txt (as root, with any text editor). Find the line: DEFAULT -> NL,California and change it into (for your specific case): DEFAULT -> US,NL on all devices. Then differentiate the white lists in each device bluetit.rc file according to the previous suggestion (subsets with empty intersection). Kind regards

@cannac Hello! In reality the problems are caused by a much more subtle cause and a bug: Bluetit uses a global connection zone list, when the country is undetermined. When you enter a country with lowercase ISO code, Bluetit does not understand it, and doesn't know where you are. Therefore it consults default connection list, which includes the Netherlands and California. In your white list, you have included at least a California server (Aquila), thus Bluetit finds at least one valid server to connect to. On the contrary, when you entered "country US", Bluetit knew that your node is in the USA: the quick connection mode excluded all the servers in the US (in accordance with the safety rule which prescribes to avoid connections to servers located in the same country your client is too), and again no valid server was found in the white list. The above will be changed in the next release where the white lists will take priority in any case for the quick connection mode, regardless of the fact that Bluetit knows or not the country of your node. Kind regards

@BKK20 Hello! The user running the client (the browser in this case) must always type the remote port when it's not 80 or 443, which are added automatically if missing. Name and port must be separated by a colon. The port is an integral and mandatory part of HTTP URL since when it was defined in 1994, 27 years ago. More in general, an HTTP URL conforms, and has always conformed, to the generic URI syntax, see also: https://en.wikipedia.org/wiki/URL Kind regards