Staff

@schwede Hello! The "nobind" line does not seem to come from the base directives, which would explain why removing it there or switching between "Append" and "Use only Custom directives" changes nothing. Eddie adds it by itself while it builds the configuration. If no network interface is selected for the connection, it would append "nobind". If one is selected, it would write "local" followed by the IP address of that interface instead. That would also explain why the line has no level comment in the preview. A solution should already exist, worth a try. In the custom directives, a directive name preceded by a minus sign will remove that directive from the final configuration and the custom directives appear to be applied after the "nobind" above. So you could try putting these two lines in Settings > OpenVPN directives, custom directives, in either mode: -nobind lport 1194 "lport" implies "bind", so "bind" should not be needed. Before connecting, you could check the result with right click on a server > More: "nobind" should be gone and "lport 1194" should be there. An alternative might be to select your LAN interface or IP in Settings > Networking (interface used for the connection): Eddie should then write "local" followed by your IP address instead of "nobind", and "lport 1194" in the custom directives should bind to that address and port. In this case, however, the preview under More would probably still show "nobind", because the interface seems to be resolved only at connection time, so the first method would be easier to verify. WireGuard: as far as we can see, Eddie currently has no option for the local port (ListenPort), so the port would be chosen randomly at each connection. By the way, a firewall that can make an exception only for a fixed local source port, and not for the remote address or port of the traffic, is highly unusual. Firewalls and traffic filters normally match outgoing UDP flows on the destination, which here would be the AirVPN entry IP addresses and ports, and that would cover both OpenVPN and WireGuard without touching the local port at all. Could you tell us which firewall or filter this is (product, model and version, or software and version) and, if possible, how the rule is configured? There might be a simpler way to solve the problem on that side. Please let us know whether the OpenVPN solution works for you. Kind regards

@voidfactory Thank you, the log you attached is exactly what was needed, and it shows the cause precisely. First, a quick picture of the pieces involved. niri is your Wayland compositor which draws and manages every window on your desktop. Eddie UI (like Discord) is an X11 application, and niri does not talk X11 itself: X11 applications run through xwayland-satellite, a bridge that starts Xwayland, acts as the X11 window manager towards those applications and presents each X11 window to niri as a normal Wayland window. All your X11 applications share that single bridge and its single connection to niri. When you activate Network Lock, Eddie opens a small dialog window. That window declares a minimum height of -5 pixels in its X11 size hints (WM_NORMAL_HINTS: min_size 102x-5). xwayland-satellite passes this value unchanged to the compositor as the Wayland minimum size, and the Wayland protocol (xdg_toplevel.set_min_size) forbids negative values: niri answers with a protocol error, the connection is closed and xwayland-satellite panics in the same second: Since every X11 application goes through that same bridge, all of them lose their display at that moment, which is why Discord goes down too, and eddie-tray then segfaults (the core dump you found) as a consequence. niri itself keeps running and quietly restarts xwayland-satellite, without telling anyone that it has just crashed: no notification, no warning, just a fresh bridge where the old one used to be, in the best tradition of a strict code of silence. The only visible symptom is your X11 applications vanishing all at once, and nobody saw anything. In other words, a single window asking to be at least minus five pixels tall is enough to take down every X11 application on your desktop: quite a lot of power for a negative number. So this is neither a permissions problem nor the Mesa issue we mentioned earlier, which is why updating xwayland-satellite did not help. Two things are wrong here: the negative value in that Eddie dialog, which we will report to the Eddie developers, and xwayland-satellite crashing on it instead of ignoring or clamping it. A regular Xwayland or X11 session tolerates such a hint, which is why the problem appears only under xwayland-satellite. If you like, you can report it to the xwayland-satellite project with the lines above: https://github.com/Supreeeme/xwayland-satellite/issues Until one of the two is fixed, on niri please use one of the options that do not need X at all, both with Network Lock: - Eddie CLI edition (eddie-cli) - AirVPN Suite (Bluetit daemon and Goldcrest client): https://airvpn.org/linux/suite/ About video playback on Viki and WeTV: it is not related to this crash. If it happens only while connected to the VPN, please try a few different servers and let us know. Kind regards

Hello, yes, this is expected. When you are connected through Eddie, your DNS queries go to the DNS resolver of the VPN server you are connected to, and this resolver does not perform DNSSEC validation. dnscheck.tools checks whether your resolver rejects records with invalid or missing signatures; ours does not, while Quad9 and Cloudflare do, hence the different results. This is intentional. Our resolvers modify some answers on purpose: the block lists and custom answers you can configure on the DNS page of the Client Area, the OpenNIC TLDs and some names used by our own services. Altering answers is exactly what DNSSEC is designed to detect and reject, so DNSSEC validation would break these features. DNSSEC validation is not strictly necessary while you are connected to the VPN. Between your device and our resolver, queries and answers travel inside the encrypted tunnel, so they cannot be forged by your local network or by your ISP. Moreover, for connections protected by TLS, such as HTTPS, a forged answer leads to a certificate error, not to a silent redirection. If you want DNSSEC validation anyway, you can run your own validating recursive resolver (for example Unbound) and let its queries go through the VPN tunnel. Please note that it must resolve recursively by itself: if it forwards queries to our resolver, validation will fail, because our resolver does not return DNSSEC signatures. You would also lose our block lists, custom answers and OpenNIC resolution. Kind regards

Hello! Discord crashing at the same moment is the key detail: the X server itself is going away, not only Eddie. Eddie's UI is an X11 (Mono WinForms) application, so on Niri it runs through xwayland-satellite, like Discord. "X connection to :0 broken (explicit kill or server shutdown)" is what every X11 client prints when that server disappears, and the Mono SIGSEGV in your second message is most likely Eddie dying after it lost its display. It is not a permissions issue: elevation through pkexec worked and the privileged part started correctly. The trigger is consistent: activating Network Lock. Eddie keeps the Network Lock state in its profile folder and applies it again at the next start, so the same step runs at every launch until you delete ~/.config/eddie. You don't need to delete it: just make sure Network Lock is off before closing Eddie, and the next start will be clean. Important: if Eddie crashes while Network Lock is active, the firewall rules stay in place by design (that's what prevents leaks), so you may have no connectivity afterwards. Start Eddie again and deactivate Network Lock, or check the rules with: sudo nft list ruleset To see which process actually crashes, please run this right after a crash and post the output: coredumpctl list --since "10 min ago" journalctl --user -b --since "10 min ago" | grep -i -E "xwayland|satellite" If xwayland-satellite shows up there, the problem is on the compositor side. Niri users have reported random crashes with exactly this message, fixed by updating xwayland-satellite (the -git version) or, in some cases, by going back to an older Mesa release: https://github.com/niri-wm/niri/issues/3199 Please also tell us your xwayland-satellite and Mesa versions. If you can, a quick test in a session with standard Xwayland (Plasma or GNOME) would confirm it: if Network Lock works there, Eddie's firewall part is fine. About leftovers: the different Eddie builds share only the profile folder ~/.config/eddie, and the AppImage is self-contained. Just check that a single Eddie package is installed: pacman -Qs eddie In the meantime, two options that do not need X at all, both with Network Lock: - Eddie CLI edition (eddie-cli) - AirVPN Suite (Bluetit daemon and Goldcrest client): https://airvpn.org/linux/suite/ Kind regards

Hello! You can generate the configuration files with our Config Generator: https://airvpn.org/generator For the QVPN Service 3 app on QNAP, a user has written a short step-by-step guide that needs no SSH: https://airvpn.org/forums/topic/73948-connect-qnap-qvpn-service-3-to-airvpn/?tab=comments#comment-253561 In short: 1. In the Config Generator turn on the advanced options and select: IPv4 only for entry and exit, OpenVPN profile 2.6 no-DCO, cipher automatic, separate keys and certificates, Linux as the system, and an OpenVPN UDP mode with tls-crypt. Choose your server or country and generate the files. 2. Rename user.crt to client.crt and user.key to client.key, and change the "cert" and "key" lines in the .ovpn file accordingly. 3. QVPN does not ask for the tls-crypt key file, so in the .ovpn file replace the line tls-crypt "tls-crypt.key" with the content of tls-crypt.key between <tls-crypt> and </tls-crypt>. 4. Import the .ovpn file and the certificate files in QVPN. If the connection fails, please post the QVPN log and your QTS version. Kind regards

Hello! Thank you for reporting it. This was a problem on our side: right after your payment our system wrongly marked your order as cancelled, which removed the plan from your account, so Eddie reported that a subscription was required. It has been corrected the same day: your one-year plan is active, and we sent you the details in your support ticket. In Eddie, please log out and log in again, or quit and restart Eddie, so that it reads the updated account status. If Eddie still shows the same message, please reply to your support ticket rather than here, so we can check your account privately. Kind regards

Hello! Nothing was blocked: that page comes from our website, not from the VPN server, and it has nothing to do with Flegetonte or with ESET. When you use the forum search without being logged in, the forum software allows one search every few seconds per browser. A new search within that interval is answered with a "Too Many Requests" error, and our web server displays it with that generic page. Its text about a suspended IP address is misleadin or range was suspended, and the limit for logged-in members is different, which is why logging in solved it. If it happens again, simply wait a few seconds before searching again. About ESET: we do not block our own servers, so the block came from ESET itself, for example from its web or network protection or from an IP reputation list. If you post the exact and the blocked address or URL, without your own IPaddress), we can check it. If it turns out to be a false positive, you can also report it to ESET from the notification or through their false positive submission. Kind regards

Hello! AirVPN is not affected. All our websites and web services (airvpn.org and our other domains) use Let's Encrypt certificates, which chain to ISRG Root X1. No eMudhra root or intermediate certificate is part of any of our certificate chains. The VPN connections do not depend on public certificate authorities at all: OpenVPN: your client authenticates our servers only against AirVPN's own private CA, which is included in your configuration file. A certificate issued by any public CA, eMudhra included, is rejected. WireGuard: there are no certificates. The server is authenticated by its public key, which is also in your configuration file. Eddie: it communicates with our infrastructure through a channel encrypted and authenticated with an RSA key built into Eddie itself, so it does not rely on the certificate store of your system. Since the tunnel is authenticated this way, someone on your local network or at your ISP cannot use a forged public certificate to get between you and our VPN servers. The remaining risk is the general one that applies to every website: a person who holds one of the compromised intermediate keys could forge a certificate for any domain, and a browser or operating system that has not received the block could accept it. Mozilla, Google, Apple and Microsoft have already revoked and blocked the affected certificates, thus upgrade asap. Kind regards

Hello, You are not missing a step. "Don't ask elevation every run" makes Eddie install a systemd unit, eddie-elevated.service. When that unit cannot be created, the option switches itself off again, which is what you see. The AUR eddie-ui package is currently Eddie 2.26.2, the latest stable release. In that version the elevated helper creates the unit only when systemd-resolved is active. Otherwise it logs "Can't create service in this OS", even on a regular systemd system. Arch does not enable systemd-resolved by default, so this check fails there. Running Eddie with sudo makes no difference. Please check that this is your case: pacman -Q eddie-ui systemctl is-active systemd-resolved If the first shows 2.26.2 and the second says "inactive", that is the cause. This is fixed in Eddie 2.27.x, currently 2.27.2 (experimental). It is available on AUR as eddie-ui-git, which replaces eddie-ui. To use it: 1. Install eddie-ui-git with your AUR helper, accepting the removal of eddie-ui. 2. Start Eddie as your normal user, not with sudo. Eddie elevates only its helper and asks for your password through polkit. 3. Enable "Don't ask elevation every run" in Preferences and authenticate once. 4. Check that the service is active: systemctl status eddie-elevated If you prefer to stay on the stable 2.26.2 release, Eddie works normally, but it will ask for elevation at each start. If your output is different, or the option still does not persist on 2.27.2, please post both command outputs and a system report, following the instructions here: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do Kind regards

Hello, "Failed - Network error" is the message Chrome, Edge and other Chromium browsers show when a download is interrupted before it completes, so we need a few details to understand where it breaks: 1. What are you trying to download? Eddie (which version and operating system), another file from our website, or any file while you are connected to AirVPN? 2. Does the same download work when you are NOT connected to the VPN? And when connected, does it fail on every server or only on some? 3. If you are connected through AirVPN when it fails: which client (Eddie, WireGuard, OpenVPN), which protocol and which server? In the meantime, please try: another browser (for example Firefox), or a private window with extensions disabled; temporarily disabling the download/web scanning of your antivirus, which often interrupts downloads with exactly this error; if you are on the VPN, another server, or switching between WireGuard and OpenVPN. Kind regards

@Nitrox Hello! Thank you for the report, it shows the cause. Your system has two Eddie tunnel adapters, "Eddie" and "Eddie 1". "Eddie 1" was left behind by an earlier session that did not close properly (the log starts with "Recovery. Unexpected crash?"): even after Eddie has disconnected, it is still up with a VPN address and it still holds the VPN routes 0.0.0.0/1 and 128.0.0.0/1. When Eddie connects, the new tunnel itself works (the WireGuard handshake succeeds), but Windows answers that the VPN routes "already exist", so your traffic goes to the stale adapter instead of the new tunnel. The route check then times out, Eddie disconnects and tries the next server, which is the loop you see. After Eddie gives up, those leftover routes still capture all your traffic, which is why the internet stays blocked until you restart: the restart removes the stale adapter. To fix it: 1. Close Eddie completely. 2. Restart Windows using Start > Power > Restart, not Shut down followed by powering on. With Windows Fast Startup enabled (the default), a shutdown does not fully reset the system, while Restart always does. 3. If the problem comes back, close Eddie, open Device Manager, select View > Show hidden devices, expand "Network adapters" and uninstall every "Eddie Tunnel" entry (for example "Eddie Tunnel" and "Eddie Tunnel #2"). Then restart Windows (Restart, as above) and start Eddie, which will create a new adapter when it connects. If the problem persists after these steps, please attach a new system report generated right after a failed connection attempt, before closing Eddie or restarting Windows. Kind regards

Hello! Please ignore our previous message in this thread: it was meant for another topic. Deleted. This error is caused by a bug of Eddie 2.26.2 (and earlier) on macOS. To check the application's integrity, Eddie stores a small file in the system folder /Library/PrivilegedHelperTools. On Macs where that folder does not exist yet, because no other application has created it, the file cannot be saved and Eddie refuses to start with exactly this message. The bug is fixed in Eddie 2.27.2 beta. Please download it from here: https://airvpn.org/forums/topic/81340-eddie-desktop-edition-227-beta-released/ Select the right package for your Mac (Apple Silicon or Intel), quit Eddie, copy the new Eddie into your Applications folder replacing the old one, then open it from Applications. Your settings are kept. If the error still appears with 2.27.2, please post the complete message: this version also prints the reason of the failure in parentheses, which tells us what is going wrong. Kind regards

@dmandingo Hello! The cause is the very old Eddie version. After our recent server upgrades, Eddie 2.16.3 no longer recognizes the connection modes offered by our servers as compatible, so it has no server it can connect to, even though nothing changed on your computer. This is why the "Connect to a recommended server" button is grayed out and why the protocol choice cannot be saved. Your account is not the problem. Windows 7 is no longer supported: current Eddie releases (2.26 and later) do not run on it, and no fixes are planned for it. Two options remain, both without guarantee: 1. Eddie 2.24.6, the last version that runs on Windows 7: https://airvpn.org/windows/ > "Other versions" > 2.24.6 > "Windows 8 / 7". It needs Microsoft .NET Framework 4.8, and on some Windows 7 computers it cannot install its network drivers. OR 2. The official WireGuard client 0.5.3, the last release for Windows 7, with a configuration file from our Config Generator (https://airvpn.org/generator/). Support team sent you the detailed step-by-step instructions for both options in reply to your support ticket. The reliable long-term solution is a computer with a supported operating system (Windows 10 or 11, Linux or macOS) and the current Eddie, which works with the same account. Kind regards

Hello! Assuming that you run Eddie Android edition, please check (tick) "Do not show anymore" at the bottom of the image, then select "Ok". Kind regards

Problem solved. Kind regards