Staff

Hello! You might be running an nft version that supported a different syntax, or this was a peculiar error in Eddie 2.19.7. Please try to rename the "nft" utility as a momentary workaround. Eddie should fall back to iptables-legacy (if we're not mistaken that's supported in your system) and the problem should be resolved. From your description we also infer that you can't run Eddie 2.24 beta testing version in your system; if that's correct, feel free (if you haven't already done so) to warn the developers in this thread: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ Kind regards

Hello! Yes, as you can see on the forum all the users who had the obsolete ca.crt resolved the issue and the same happened to those who opened a ticket. Which Operating System and which OpenVPN version do you still experience the problem with? Can we see the OpenVPN log taken after a connection attempt has failed? Kind regards

Hello! Again: Apr 13 02:18:01 openvpn 39844 SIGTERM[soft,auth-failure] received, process exiting Apr 13 02:18:01 openvpn 39844 TCP/UDP: Closing socket Apr 13 02:18:01 openvpn 39844 AUTH: Received control message: AUTH_FAILED You renewed your client certificate a few hours ago, and locally you have the previous certificate (which is no more valid due to the renewal you did). This is confirmed as the current user.crt certificate of yours expires in 2034, but locally you have: showing that you have the old certificate you revoked. EDIT: remember to update again the user.key too. Kind regards

Hello! Authorization failure. Can you please re-check your user.crt and user.key too? Kind regards

Hello! What you can do is binding a program to a network interface. In macOS the VPN interface name is "utunx" where x is a digit. By binding the torrent program to the proper utun interface you will prevent traffic leaks outside the VPN tunnel (of the torrent program only, of course). Various torrent programs offer this feature in the settings, but probably not all of them. To prevent traffic leaks in any case, and even for those programs that don't offer a bind option, please enable the "Network Lock" feature available on AirVPN software (Eddie macOS edition). Network Lock is a set of firewall rules which will prevent any possible traffic leak. The rules remain in place until you don't explicitly disable them or you cleanly shut down Eddie. Kind regards

@Sister123 Hello! Yes, it's safe, and you could even get better performance. The outcome shows that there is no general UDP block. Either the check route failure recorded by Eddie is a false positive, or there is actually something blocking OpenVPN when it works in UDP to port 443. To quickly discern (if you are curious to know) you could disable route and DNS check, go back to OpenVPN and verify whether the connection is successful: switch back to the previous OpenVPN + UDP port 443 connection mode from Eddie's main window select "Preferences" > "Advanced" uncheck "Check if the VPN tunnel works" click "Save" select "Preferences" > "DNS" uncheck "Check Air VPN DNS" click "Save" enable Network Lock try again a connection and test whether traffic goes through If the connection is successful and the traffic goes through fine, then Eddie is wrong and the route check failure is a false positive (for unknown reasons, at the moment). Otherwise, there's really something interfering, in which case you can check any packet filtering tool both on your router and system. In this last case, if you find nothing blocking then the block is most probably enforced by your ISP. Kind regards

@Sister123 Hello! To verify whether it's some block against UDP or not, could you please test a connection over WireGuard and check whether it goes through successfully? To switch to WireGuard: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select any line with WireGuard, for example WireGuard port 51820. The line will be highlighted click "Save" and test again connections to various servers Kind regards

@JackParsons Hello! Eddie 2.13.6 should run on your system. To download it, on the Linux download page please select "Other versions", click "2.13.6" and the download page will point to that version. Before installing Eddie 2.13.6 please make sure to delete the configuration file (default.xml in older Eddie versions, default.profile in newer version) to avoid incompatibilities of the configuration file due to a downgrade. If even Eddie 2.13.6 can't run on your system, then you could prepare a configuration file compatible with your OpenVPN 2.3.2: in the Configuration Generator turn the "Advanced" switch on set the "OpenVPN profile" combo box to "2.4" select a connection with OpenVPN to entry-IP address ONE (this is essential to avoid tls-crypt, unsupported by 2.3) download and use the configuration file as usual Please consider anyway to upgrade your system for security reasons. Kind regards

Hello! The Configuration Generator is (and was) able to generate either separate files or configuration files embedded with certificates and keys, according to your selection. Therefore it is possible that you have a configuration file embedded with the certificate causing the problem. However, from your previous message, it is also visible that you had an expired ca.crt in ~/Downloads/AirVPN Kind regards

Hello, it seems there are no news since March 2023. Latest Action: Senate - 03/07/2023 Read twice and referred to the Committee on Commerce, Science, and Transportation. Source: web site of the Congress of the USA https://www.congress.gov/bill/118th-congress/senate-bill/686/text Kind regards

Hello! Please enable "Advanced" mode in the Configuration Generator, pick a connection mode with entry-IP address 1 (one) and check "Split certs/keys from ovpn file". When you generate the configuration you will obtain a ta.key. The reason is that the obsolete TLS Auth mode and the new TLS Crypt mode are mutually incompatible. In order to keep compatibility with old OpenVPN versions we need to differentiate OpenVPN daemons working on TLS Crypt from those working on TLS Auth. In general, OpenVPN responding on VPN servers entry IP addresses 1 and 2 support TLS Auth, while OpenVPN on entry IP addresses 3 and 4 support TLS Crypt. More details on the technical specifications page https://airvpn.org/specs OSMC is a Linux distribution based on Debian and Kodi so installing WireGuard should be a matter of seconds, if it is available in the repos. Since OSMC moved to Bullseye in 2022, you could have WireGuard ready. Try to install it and check. sudo apt install wireguard-tools sudo apt install openresolv If the installation is successful you can follow the instructions for Linux to set up WireGuard in a minute or so, let us know. Of course not! ca.crt was renewed in 2021 with expiration date 2121. Your ca.crt, emitted in 2014 with expiration date 2024, was downloaded before the 2021 renewal. The Configuration Generator has never served an expired certificate. Kind regards

Hello! It looks like the problem has been solved, we already have a couple of servers approaching 1.5 Gbit/s, can you please confirm? Kind regards

@alanm Hello! The problem seems related to TLS Crypt authentication (you connect to an entry-IP address three). You should re-check that you have the correct TLS Crypt key and configuration: TLS Configuration = Use a TLS Key (checked) Automatically generate a TLS Key (unchecked) TLS Key = Paste contents of the tls-crypt.key downloaded here TLS Key Usage Mode = TLS Encryption and Authentication TLS keydir = use default direction or you can go back to TLS Auth, with the ta.key and entry-IP address 1. More in general, you're running an indeed obsolete OpenVPN version, please consider to upgrade, or even switch to WireGuard if you like. @juniormaxx This great guide is very good for pfSense versions running OpenVPN 2.5 and OpenVPN 2.6 with DCO disabled. https://nguvu.org/pfsense/pfsense-baseline-setup/ Kind regards

@eltznth Hello! Yes, TLS Crypt seems fully supported. Set the "TLS Control Channel security" combo box to "Encrypt channel" Set the "Compression" combo box to "LZO Adaptive" Check "Verify certificate" Do not enable server certificate verification by name, leave the "Verify server certificate" combo box to "No". Kind regards

Hello! No. ca.crt emitted in 2021 expires in 2121. You have installed a ca.crt downloaded before 2021: up to the renewal in 2021, ca.crt emitted in 2014 expired in 2024, as you have seen. Two options: Please generate a new configuration file in the Configuration Generator with the "Advanced" mode enabled and the "Split certs/keys from ovpn files" checked. Download the generated ca.crt certificate and replace, with it, the old one. Alternatively, switch to WireGuard. Kind regards

Hello! We're not 100% sure, but the "Compression" combo box set to "LZO" could create a problem with "comp-lzo no" directive. Which options do you have available in the "Compression" combo box? If available, please try with "Adaptive" and do not touch "comp-lzo no". Also check "Verify server certificate". 198.54.134.254 is an entry-IP address #3 where OpenVPN accepts TLS Crypt only. Please double-check that you have (in the proper static key field) pasted the TLS Crypt key (tls-crypt.key). Last but not least, which options do you have in "TLS Control channel security" combo box? Kind regards

Hello! No maintenance is ongoing on the CZ servers but the anomalous throughput you noticed is real. Sudden bandwidth choking is recorded ever since 1 PM UTC (Apr 10 2024). No flood and no packet loss is ongoing. If the problem does not get solved within 6 hours we will contact the datacenter technicians for support. Please connect to servers outside CZ in the meantime, when you need maximum performance. Kind regards

Hello! Please check ca.crt. From the couple of log lines you sent us we may speculate that you still have an old ca.crt. It's strange because in February 2022 ca.crt was already the new one with expiration on 2121, so we might be missing something here. Is everything fine with Eddie (do not run OpenVPN at all)? Can we see the complete OpenVPN log and can you tell us your exact Operating System name and version? Kind regards

Would you mind sharing your config? It seems we have the same or similar problem. Also useful for the How-to post. You can see it in the initial post. The corrections required are listed in our reply (the message set as "best answer" by the OP). If you still experience problems please post your configuration, similarly to what OP did. Kind regards

Hello! Excellent, we're glad to know that the cause of the problem was found and that the problem is solved. In the past, that bug was not critical. Anyway your OpenVPN version is becoming obsolete therefore an upgrade in the near future, with no time pressure now that everything works, is recommended. Newest versions also support WireGuard, which could give you a remarkable performance boost. The DD-WRT settings you posted in another message could be improved to slightly enhance performance with this router that does not support AES-NI. Try to change the "Encryption cipher" and the first "Data cipher" to CHACHA20-POLY1305 (if available) and check whether performance increases or not. Kind regards

Hello! You need to re-generate your configuration files through the Configuration Generator available in your AirVPN account "Client Area". Explanation: https://airvpn.org/forums/topic/58289-openvpn-certificate-has-expired/?do=findComment&comment=231319 Kind regards

Hello! Please see here for a possible explanation and easy solution: https://airvpn.org/forums/topic/58289-openvpn-certificate-has-expired/?tab=comments#comment-231319 Kind regards

@sdjh4dfgez7 Hello! We see at least one critical error at the moment, "Compression" combo box must be set to "Adaptive", otherwise your "comp-lzo no" directive (which is correct and must not be deleted) will cause a fatal conflict with the "Disabled" setting. Let us know what happens when "Compression" is set to "Adaptive". Note: if "Adaptive" is not available, set it to "Enabled" (then comp-lzo no will disable it during the negotiation). Also, please check "Verify certificate" and change data-ciphers to AES-256-GCM or CHACHA20-POLY1305. Kind regards

@clevoir Hello! We see a date/time problem, when OpenVPN starts the date of the router is still 1970 and it could cause a fatal TLS failure. When the initial packet is received the date seems to be set correctly, but it's unclear whether the previous past date may have already caused a problem, because: Assuming that the problem is not related to date and time, UDP seems blocked, or maybe it's a block against OpenVPN. You're using TLS Auth (correctly to entry-IP address 1) with OpenVPN 2.5. You may change to TLS Crypt and test again (remember to switch to entry-IP address 3 as well). Also switch to TCP if the block persists. In the last part of the log a notorious bug is visible (the cycle between disconnections and connections according to management). Usually this is not relevant but if you have the option to upgrade please do it. As you can see the date and time is again reset to UNIX 0 after the Client management disconnect/connect cycle, and this could be critical. In any case, the fact that the date is suddenly reset makes a firmware upgrade recommended. Before upgrading, anyway, please test again but this time make sure to start the connection when the date and time are already set correctly. Please send also a screenshot of all the various settings of the OpenVPN DD-WRT panel. Kind regards

Hello! Please post OpenVPN log taken after a connection attempt has failed. Kind regards