Leaderboard

Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.24 beta. It is ready for public beta testing. How to test our experimental release: Go to download page of your OS Click the button Switch to EXPERIMENTAL Download and install This is a new version of Eddie Desktop (Windows / Linux / MacOS). We know there is still 2.21.8 as stable, and 2.22.x and 2.23.x series never reached the stable version. We hope that this version 2.24.x will be tested and reach a stable release. Internally (in terms of development and code) it represents a significant step forward for us: the CLI editions are compiled with dotnet 7, without Mono, Xamarin and any dependency on NetFramework (Windows) or Mono (Linux, MacOS). All CLI projects can be opened in Visual Studio Code and debugged on any OS (macOS, Linux, Windows) without the need to use Xamarin, Visual Studio or Visual Studio for Mac. A new UI is in the works that will finally remove the dependency on Mono and Xamarin, but we don't have a release date to announce yet. The MacOS CLI is new (previously there was only the UI, or the UI with "-cli"), and it's also native for arm64. Overall, there has been a significant effort to clean up and modernise the code, and to prepare our build/deploy scripts for the new UI as well. We understand that there are still tickets or posts that we haven't responded to yet, but we preferred to complete this step first. Main changelog: [new] WireGuard is now the default communication protocol [new] All CLI editions can be compiled and debugged with VSCode and .NET7 [new] [macOS] CLI-only edition, built with .NET7, without Xamarin [new] New commandline only option "elevated.method" [change] OpenVPN 2.6.9 [change] [linux] CLI edition, built with .NET7, without Mono [change] [linux] .deb and .rpm, removed Mono dependency [change] [linux] .deb package tries to initialize elevated service at install/uninstall, .rpm package still missing this feature. [change] [windows] CLI edition, built with .NET7 [change] [all] Better management of SIGTERM signal [change] [all] Don't check if app dir is writable for portable-mode, now managed by presence of "portable.txt". [bugfix] [linux] terminal issue with sudo elevation [deprecation] [all] -cli mode for UI. Use CLI edition directly, now available in all supported platform. [deprecation] [windows] Vista builds [deprecation] [windows] Windows Firewall Network Lock mode [deprecation] [linux] x86 builds [deprecation] [linux] Portable Mono builds

@Greyzy Hello! The domain name included in the configuration file generated by the Configuration Generator is fully qualified, as you can verify independently. The problem is always the same as you can see even from nslookup: poisoned/wrong resolution (into a non-routable address). The problem is not in domain names or configuration files. Specific example for de3.vpn.airdns.org: note how Quad9 (9.9.9.9) resolves correctly and this adds another strange piece to the puzzle because nslookup said that it queried Quad9 to resolve de3.vpn.airdns.org, but gets an answer that surely does not come from Quad9. This suggests some worrying scenario, but don't let us jump to conclusions too early: just switch to DNS over TLS (supported by Quad9). Configuration needs a little bit of documentation, please check (while you are in the VPN): https://www.elevenforum.com/t/enable-dns-over-tls-dot-in-windows-11.9012/ DNS over TLS will ensure that your DNS queries will not be tampered by your ISP or any MITM (when you are in the VPN you are already protected as the DNS is inside the VPN, but when you're not connected to the VPN you're not protected). $ drill @9.9.9.9 de3.vpn.airdns.org ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 27288 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; de3.vpn.airdns.org. IN A ;; ANSWER SECTION: de3.vpn.airdns.org. 300 IN A 37.120.217.245 ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 151 msec ;; SERVER: 9.9.9.9 ;; WHEN: Wed Jun 26 20:58:14 2024 ;; MSG SIZE rcvd: 52 Also, please answer to the relevant question by @go558a83nk Kind regards

Disconnect from the VPN and do the tests again. TCP Optimizer for Windows has got a nice feature to determine the max MTU for you. Assuming it will show you 1500, it means for UDP: Max size - IP header = 1472 bytes. Max size - (IP header + OpenVPN header) = 1392 bytes. If you lower the MTU, say, by 28 bytes, you get a lower size in both scenarios which wouldn't be your max: (Max size - 28 bytes) - IP header = 1444 bytes (Max size - 28 bytes) - (IP header + OpenVPN header) = 1364 bytes Ergo, don't worry about MTU, just use your max. If you use Windows, I recommend starting the program above with admin rights and do the TCP optimizations for your download speed. Windows' defaults are not the best.