Staff

@matteoar1 Hello! Plex ignores your setting (port 63162 does not appear anywhere). From the documentation, we can infer that the "public port" is only used to announce it through Plex centralized system to clients to facilitate connections, authentication and other purposes, and then it is required that some Plex upstream (the router or system packet mangling tool) re-directs incoming packets to port 32400. Try to re-map port 63162 to your port 32400. If Plex announces to clients public port 63162, clients will contact AirVPN server IP address on port 63162 and the server will forward the packets to your Mac utun interface port 32400. Since Plex listens to port 32400 of all interfaces in IPv4 and IPv6: Plex\x20M 728 matteo 18u IPv6 0x5e8f1037afa692f5 0t0 TCP *:32400 (LISTEN) (about why lsof in BSD and Linux shows an IPv4 and IPv6 socket only as IPv6 see here) then your Plex should become reachable. In order to do so just add "32400" to the "Local" field of your remote port 63162, in your AirVPN account port panel. Kind regards

Please open a new thread, this is outdated and caused by Windows and the TAP adapter driver, not Eddie. Specifically, the problem was partially reproducible with old Eddie version using TAP adapter driver and interface instead of the Wintun driver. If you find this problem with Windows 10 or 11 and Wintun driver chances are that it's a different issue, therefore worth of a new thread. If the problem occurs when you run Eddie 2.24 please feel free to add it on the following thread: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ Kind regards

Hello! While the system is connected to the VPN and Plex is running please open a terminal and enter the following command: sudo lsof -i -n -P | grep -i plex Then copy and paste in your next message the whole output. The method suggests enabling IP forwarding and redirecting all packets destined for Plex to the physical network interface port 32400, as if Plex were a very peculiar server unable to listen on the VPN interface. If that's the case yes, you will need that, but we refuse to think that Plex is so junky with this basic feature. Furthermore the method uses pf for packet mangling and therefore it may interfere with Network Lock, which uses pf too. According to other customers (but please note that we do not use Plex) this method is not applied in recent Plex releases and everything works as it should. Kind regards

@matteoar1 Hello! At least you now know that your VPN and system settings are correct and that the VPN remote inbound port forwarding system works properly. We would like to see, while the system is connected to the VPN and Plex is running, which interface(s):port Plex listens to. How to print such info varies from system to system: can you tell us your Operating System name and version? Kind regards

@matteoar1 Hello! We get a "connection refused" (error 111) when a packet is sent to your VPN client port 63162. The packet reaches your node and the connection is actively reset. It's possible that a firewall rejects the packet (instead of silently dropping it) or that nothing listens to port 63162 and the system is configured to reset any attempted connection when the destination port doesn't exist. This fact seems to confirm that the problem is with Plex. Unfortunately we can't see a reason, with the current information, to explain how it's possible that Plex works fine for some time and then stops working (maybe some firewall rule which is enforced with some delay? but this sounds like a wild speculation...). Can you please run anything else listening to VPN interface port 63162, while the system is connected to the VPN, and check what happens? Kind regards

@v0e#nuy Hello! When Bluetit connection mode is set to country, Bluetit calls on domain names to get the destination server IP address (this feature is being completely rewritten and in the next versions domain names will not be used anymore). When a domain name can't be resolved the connection attempt unavoidably fails. In your situation the name resolution is impossible as the system DNS seems unreachable, and actually the DNS server address is private; it is perhaps a spurious remnant from some previous session: You can restore proper DNS settings and/or consider not relying on domain names by creating a white list of your favourite servers in Japan. When a white list of servers is created and the connection mode is set to quick (e.g. airconnectatboot quick in the run control file), Bluetit will select the best rated server in the white list. Example for bluetit.rc: airconnectatboot quick airwhiteserverlist Ainalrami,Albaldah,Bharani,Biham,Fleed,Iskandar,Okab,Taphao Kind regards

@Jimmyboy52 Hello! Apparently Eddie does not follow your settings (you ordered a connection in TCP and Eddie keeps trying in UDP) therefore we suspect that the configuration file is corrupt. Please try the following procedure: make sure that Eddie is not running delete the file C:\Users\Joey\AppData\Local\Eddie\default.profile: from a command prompt enter the command del C:\Users\Joey\AppData\Local\Eddie\default.profile re-start Eddie and test again connections both in UDP and TCP Also, please test WireGuard, no matter whether the problem got resolved or not: 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 re-start a connection to apply the change please make sure to test a few servers in different locations around your node Kind regards

@OhioStateHack Hello! Apparently either UDP or OpenVPN is/are blocked: Please check any packet filtering tool both on your router and system and make sure they do not block UDP. Also test a connection over WireGuard. WireGuard works in UDP too so you can have a first discernment. In order 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 re-start a connection to apply the change Please make sure to test a few servers in different locations around your node. Kind regards

@BettyIsBoop @mnzx and anyone with the error "System.TypeInitializationException" Confirmed, hopefully this will be fixed in the next release. As a workaround for now, please install mono-runtime-common: sudo apt install mono-runtime-common @svenmaninov : Hi, it's expected. There shouldn't be any Mono dependency theoretically as it's bundled now. However, there is an issue that is being investigated.

Confirmed, will be fixed in 2.24.2.

Hello! Does the problem persist with the new 2.24.1 (upgrade if you haven't already done so), released after you posted the issue? If it persists, please feel free to add on the mentioned thread your report. Kind regards

Version 2.24.1 with some bugfixes released. In some packages, WireGuard was not the default, fixed in 2.24.1. As soon as possible. Tray icon should be fixed in 2.24.1 Fixed in 2.24.1, same issue also for @drum Both under investigation, thank you for your tests and patience! Under investigation, thank you for your tests and patience! Kind regards

@BettyIsBoop Can you please post your message in the following thread: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ It's the thread followed by devs for bug reports on 2.24. Thank you in advance! Kind regards

@Tavvy This error related to the virtual interface tun0 did not occur with Eddie 2.21.8, can you confirm? Please feel free to add your message (or we can do it for you) to the following thread: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ where bugs discovered by the community are reported, thank you very much. In any case we will highlight your report to developers. Kind regards

@Moneytinker Hello! For an explanation and a quick solution please see here: https://airvpn.org/forums/topic/56643-stuck-in-a-broken-route-never-connects/?do=findComment&comment=225323 Kind regards

Hello! Currently, we have no plans for Obsfproxy: throughout the years we have been very focused on leaving the need for this kind of obfuscation to the Tor network (in which we have invested a lot of time and resources), but we may consider it in the future. Kind regards

Hello! The explanation that comes to mind is that you ran OpenVPN without DNS management (in Linux and FreeBSD OpenVPN doesn't manage DNS by itself), while Eddie by default works to avoid any possible DNS leak (outside the VPN tunnel) and use VPN DNS only. If you accessed shares or any other local resource via hostnames unknown to VPN DNS but known to your local DNS the described problem is explained. It is anyway possible to configure Eddie to use any DNS you like or not to touch the DNS settings of the machine. Kind regards

Hello! Please test Eddie 2.24: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ Eddie features support with proper DNS management for every systemd-resolved (a ramshackle systemd component that would have the ambition to offer name resolution to applications) mode from version 2.23.2. Previous versions do not handle correctly a specific systemd-resolved working mode which will cause DNS leaks. If you're running some older Eddie version, including the current stable release, and your Mint has systemd-resolved running and working in on-link mode bypassing /etc/resolv.conf, we may have a rational explanation of the situation. However, the discrepancy between https://ipleak.net and the web site you mention remains unexplained. Kind regards

Hello! Chances are that your system DNS settings are incorrect. Please check and make sure that, while Eddie or any VPN program is not running, the system can use publicly available DNS servers. We recommend Quad9 (9.9.9.9) and OpenNIC for their commitment to privacy and neutrality. Kind regards

Hello! We were easy prophets in this case. The catastrophic blackout referred to in the article is a concrete example of the risk we denounced, a violation of fundamental rights, a confirmation of the wisdom of our decision and a demonstration of the irresponsible and odious frivolity of decisions taken by private actors. Our infrastructure must not be polluted by repugnant decisions taken by private entities that seem to have little or no technical competence and that, so far, enjoy impunity for any mistake, no matter how serious. Kind regards

Thank you for your tests! @Clodo may clarify this event. Also, does Eddie keep connecting over OpenVPN when you log your account out and in again? Kind regards

@exor41n Hello! It's unclear why the status is still dirty, according to Goldcrest, because /etc/airvpn content seems just fine. We guess that you still have the problem if you try: goldcrest --recover-network (which is the proper command to recover network when the Bluetit status is dirty). Could you please try a connection through Goldcrest without any profile? Example (from user "airvpn" or "root"): goldcrest --air-connect Then, please prepare the complete Bluetit log that you can print on file with: sudo journalctl | grep bluetit > bluetit.log and please send us the bluetit.log file you generated. Kind regards

Hello! Some preliminary considerations: https://airvpn.org/forums/topic/56989-can-the-10g-full-duplex-servers-operate-at-nearly-or-full-bandwidthcapacity/?do=findComment&comment=228405 Also, the choice is not hard coded. The connection mode picked when "Automatic" is selected may now be driven by the bootstrap servers' manifest file. We would gladly welcome feedback on the current WireGuard choice as well. Kind regards

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. This version is very close to a stable release after thorough testing by the community and subsequent bug fixing. 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

Hello! Excellent in our infrastructure even on agnostic networks. We would not modify anything else, especially because you are in a network that's shaping VPN traffic. Obfuscation in place of true encryption is less CPU intensive but the solution you adopted is solid. According to a recent paper by Usenix titled OpenVPN is Open to VPN Fingerprinting, OpenVPN over SSH has a filter rate of 0.32, making it the third best technique to defeat filters against OpenVPN. Kind regards