Staff

Hello! Can you tell us the laptop Operating System name and version? Kind regards

@AntairVPN Hello! Can you please switch to WireGuard and check whether the same problem occurs or not? In order to switch to WireGuard: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select any line with WireGuard. The line will be highlighted. click "Save" and re-start a connection to apply the change please make sure to test a few servers in different locations around your node If the problem persists, disable the route check, just in case the failure is a false positive: from Eddie's main window select "Preferences" > "Advanced" uncheck "Check if the Air VPN tunnel works" click "Save" enable "Network Lock" from the main window from Eddie's main window select "Preferences" > "DNS" uncheck "Check Air VPN DNS" click "Save" test again Kind regards

Hello! With the current information unfortunately we can't say what you should look into. Try to open a ticket and investigate together with the support team. Let them know your Operating System, the browser you run, the software you use to connect to VPN servers... probably they will ask you for even more info in an attempt to understand the cause of the problem. Kind regards

Hello! We have just tested Nahn, Pisces, Telescopium, Titawin and Sham. https://yahoo.com is perfectly reachable from all of them. The connections were performed via WireGuard and the VPN DNS (10.128.0.1) correctly resolves the name. No block of any kind has been detected. More and more it sounds like your own local problem, let's see the feedback from other users. Note that in the route checker, "301" is correct (although it is questionable that the checker displays it with a red token), as yahoo.com replies "moved permanently" to ca.yahoo.com (re-direction is fine). Kind regards

@madrat Hello! Can you give us the name of those servers you can't access yahoo.com from? Kind regards

@salvialight Hello! Please note that you resurrected an 8 years old thread. Many things have changed in the meantime. The alleged problem heavily depends on the DNS management of the software you run to connect. In general, WireGuard, Eddie (the Air software client) and the AirVPN Suite for Linux do that, while OpenVPN does not. Note: if your system runs systemd-resolved only Eddie 2.23.1 and newer versions added full support with proper DNS management for every systemd-resolved working mode. For manual DNS setup purposes, since you mention Pi OS we guess that it's the latest Pi OS based on Ubuntu 22/23, so you can consult Ubuntu, or general Linux, and systemd-resolved guides on DNS settings. Also note that only with the introduction of some new systemd-resolved "on link" working modes the "DNS leaks" plague entered the Linux world, while previously it was a Windows-only pest. Before systemd-resolved specific working modes were activated by default in various distributions, DNS leaks did not exist in Linux. it seems no accident that shady pestilence spreaders who infect Linux with endemic Windows plagues then end up hired by Microsoft. Kind regards

Hello! The following errors thrown by OpenVPN: . 2024.01.28 17:17:24 - OpenVPN > write UDP: Unknown error (code=10065) . 2024.01.28 17:17:24 - OpenVPN > write UDP: Unknown error (code=10065) . 2024.01.28 17:17:24 - OpenVPN > write UDP: Unknown error (code=10065) hint to something blocking UDP and/or OpenVPN packets. Please check any packet filtering and traffic management tools both on your system and router and make sure you remove any such block. Also test a connection over WireGuard to discern whether the block is against UDP or against OpenVPN specifically. To switch to WireGuard: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select any line with WireGuard. The line will be highlighted. click "Save" and re-start a connection to apply the change Please make sure to test various servers in different locations. Kind regards

Hello! Is that the complete error message, no additional info? Can you tell us the Operating System and whether the configuration file pertains to OpenVPN or WireGuard? Which OpenVPN or WireGuard version do you run? Kind regards

@air92186 Hello! We fear that Gluetun's server list is hard coded here: https://raw.githubusercontent.com/qdm12/gluetun/master/internal/storage/servers.json Saclateni is not included in that list, maybe the list must be updated manually? To avoid hard coded lists a developer could parse the AirVPN manifest. How to download and how to parse the manifest must be seen on Eddie Android (Java) or AirVPN Suite (C++) source code, which is (in our opinion) very readable and well commented. A developer could also use the Bluetit daemon (developer's reference manual available here) for all the needed operations for a full integration with AirVPN (Bluetit exposes a D-Bus interface), although the integration requires that the target functions and/or classes are developed according to the AirVPN–SUITE classes marshaling mechanism (thoroughly documented anyway). However, there is no official document describing the manifest format and the procedure to download it from the bootstrap servers, we're sorry. We might plan a fully documented API for third party developers so they don't need hard coded lists of servers and IP addresses, or we might document the manifest download procedure and its format... we'll think about it. Kind regards

Hello! Thank you very much, you are a long time customer! Some Eddie Linux edition versions, including 2.21.8, have a bug which causes a race condition in some cases when the round trip times tests are performed. The bug was fixed in Eddie 2.22 and the whole round trip time checks procedure was significantly improved in 2.23. From your description, we suspect that your problem is caused by the mentioned bug. Please test Eddie 2.23.2 beta and check whether the problem gets solved. Please see here to download Eddie 2.23.2 beta version: https://airvpn.org/forums/topic/56428-eddie-desktop-223-beta-released/ If you are already running Eddie 2.23.2 then the problem must have a different cause, let us know. Kind regards

Hello! Please renew your client certificate and key according to the following instructions: https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/ Reason: we signed client certificates with SHA1 between 2010 and 2017. In 2017 we started to sign them with SHA512, but the update was not forced on customers in order to avoid sudden disconnections and potential compatibility problems. You're indeed a long time customer, thank you! Nowadays OpenSSL 3 (the SSL library used by OpenVPN) considers SHA1 based signatures insecure. By renewing the certificate you will have a new certificate signed through SHA512. Please remember that you need to re-generate your configuration file(s) after you have renewed the certificate. Kind regards

@julienth Hello! Eddie picks the DCO adapter which is already installed in the system, but this adapter is incompatible with the OpenVPN version (2.5.5) in your system that Eddie itself runs. You can solve quickly the problem in this way: https://airvpn.org/forums/topic/56643-stuck-in-a-broken-route-never-connects/?do=findComment&comment=225323 Alternatively you can install OpenVPN 2.6 (which supports DCO) and force Eddie to run OpenVPN 2.6. You can configure which OpenVPN binary Eddie must run in Preferences > Advanced > OpenVPN custom path. Kind regards

Hello! Let's verify whether the route check failure is a false positive or not: from Eddie's main window select "Preferences" > "Advanced" uncheck "Check if the VPN tunnel works" click "Save" enable Network Lock from Eddie's main window select "Preferences" > "DNS" uncheck "Check Air VPN DNS" click "Save" test again connections with WireGuard and OpenVPN. This time the connection should be fine from the log, but you must verify manually that you can perform your normal Internet activity. Network Lock will prevent anyway any traffic leak and make the route check superfluous Kind regards

Hello! Why do you mention the router again? The router would not enter into play in this case of port forwarding because you wrote that the connection is established from a computer behind the router, not by the router. Can you confirm this? Kind regards

Hello! Error 111 (connection refused) imply an active connection reset. Therefore the packets correctly reached the system connected to the VPN but they were actively refused. This event may occur when a packet filtering tool is configured to reject packets (and not dropping them silently) either globally or on a specific port, or when the operating system is configured to reset incoming connection without an end-point (in other words, when no process is "listening" to the destination port). Therefore, assuming that the Synology device is connected directly to the VPN, please check your packet filtering tool rules and check the configuration of the listening Download Station: it must be running, listening to the correct port (check your AirVPN account port panel) and binding (if a bind option is available) either to all interfaces or to the virtual network interface used by the VPN program. However, if it's your router the one connecting to the VPN and then sharing the connection with all the devices behind, then you must take care to forward the router port to the final destination, in this case the proper port of the LAN IP address of the Synology device. Kind regards

@julienth Hello! If the problem persists please post or attach to a ticket a system report generated by Eddie after the problem has occurred. Please see here to do so: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ If the problem has been resolved in the meantime, please spend a minute to post the solution for all the community readers. Kind regards

Hello! Does the same problem persist if you try a connection via WireGuard? In order to switch to WireGuard: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select any line with WireGuard. The line will be highlighted. click "Save" and re-start a connection to apply the change please make sure to test a few servers in different locations around your node Kind regards

Hello! A new release is planned during April 2024. Stay tuned! Kind regards

Thank you for the head up! Problem fixed. Kind regards

Hello! This solution should work for you too: https://airvpn.org/forums/topic/56643-stuck-in-a-broken-route-never-connects/?tab=comments#comment-225323 Kind regards

Hello! It is possible, please see here: https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/ Kind regards

Hello! Before trying anything else, can you please make sure that your father's PC is really connected to the VPN? Please verify by browsing https://ipleak.net : the web site should show that the system is connected to some AirVPN servers and it should mention which server it is. For these preliminary tests please make sure to connect each device to a different VPN server: multiple connections to the same server with the same key may cause conflicts. In the future you can resolve the above problem (if you need to connect multiple devices to the same VPN server from the same account) by using unique key on each device, as AirVPN allows a thorough and flexible management of your account keys, please see here: https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/ Kind regards

Hello! The CPU of 10 Gbit/s servers does not have high load on average and the 10 Gbit/s servers have repeatedly reached more than 12 Gbit/s peak performance (6 up + 6 down). They also have quite a remarkable average, for example Haedus on weekends keeps an impressive 8 Gbit/s averaged on the 48 hours! OpenVPN surely loads the CPU, that's unavoidable, but we're topping CPU capacity only when the total amount of connected clients exceed 300, which normally should not happen: Eddie will not recommend connection to servers with approaching to limit connected clients and our areas FQDN will not resolve to those servers' IP addresses. As a side note, consider that the 10 Gbit/s servers marked with "6000 Mbit/s" maximum bandwidth are connected to a 10 Gbit/s port but with our plan the provider guarantees 3 Gbit/s full duplex 24/7, while they are "best effort" burstable to 10 Gbit/s. Kind regards

Hello! Please check your setup against the following guide: https://airvpn.org/faq/p2p/ On top of that, we have noticed a malfunction in some qBittorrent version (for example 4.5.5) in FreeBSD and Linux related to binding. If you set Tools > Preferences > Advanced > Optional IP addresses to bind to into All addresses, qBittorrent will reply only to IPv6 packets. If that's your case too, set that combo box to All IPv4 addresses. For additional safety you can also set the Network interface combo box (available in the same advanced menu) to your VPN interface. Always run qBittorrent only after a VPN connection has been successfully established. Kind regards

@shortfacedbear Hello! While Eddie Windows edition does not feature traffic splitting on an application basis (i.e. the feature you would need) WireSock for Windows has emerged in the last months as a practical and efficient solution even for your needs. https://www.wiresock.net/ On Windows, WireSock allows per app traffic splitting, per app reverse traffic splitting, per IP address destination traffic splitting, and hybrid traffic splitting with an extremely simple configuration file. According to the new reports we received from some of our Windows customers, it is probably a good solution which will save you from virtualization and from any solution requiring a fairly decent system and networking competence. According to those same reports, WireSock is fully compatible with AirVPN but unfortunately it is not open source software as far as we can see. Kind regards