Staff

@DatorGyrose Hello! It's a typical WiFi related problem magnified by the usage of a routed virtual network. The best, ideal solution is getting rid of WiFi and use only Ethernet connection. Consider this solution when applicable. When not applicable, please read this article in its entirety first and foremost: https://www.acrylicwifi.com/en/blog/why-are-wifi-channels-1-6-and-11-used-on-2-4ghz/ # for 2.4 GHz WiFi https://computermesh.com/guide-to-5ghz-wifi-best-channels-for-5ghz/ # for 5 GHz WiFi Once you have understood the problem, please make sure that you have a good WiFi signal intensity, exclude other possible, mentioned in the article, sources of interference, then proceed to select a WiFi channel that does not overlap with anything else. Help of a spectrum analyzer software is strongly recommended. If no no-overlapping channel is available (worst case scenario), make sure that the AP or router emits with an intensity of -20dbm to the rest of the interference. Final note: please make sure that when you use Ethernet the WiFi card is turned off and when you use WiFi the Ethernet cable is unplugged, in order to avoid the ambiguity of having the same default gateway on two different physical NICs with a single routing table. Kind regards

@thetechnerd Hello! Eddie Desktop edition development is active and new versions will come out in the near future. This is a correct behavior: by default two instances of Eddie can't run concurrently and you are trying to run two Eddie programs at the same time. You could force Eddie to manage multiple instances but don't do it unless you know exactly what you're doing. From your description it's clear that Eddie starts minimized. In this case you can bring up Eddie's main window by clicking or double-clicking its tray icon in the system tray. Once Eddie's main window is visible, you can modify this behavior in "Preferences" > "UI" window so that Eddie will not start minimized. By default Eddie does not start minimized so you have changed the option "Start minimized" already. Uncheck the tick box of this item and click "Save" to go back to the default behavior. Your last ticket was posted in 2024. All of your tickets have been processed and all the replies include an immediate solution to the problems that each time you experienced (most of the times caused by yourself, honestly...). If you can't read the courtesy e-mail you can consult your ticket section in your AirVPN account "Client Area" > "Support request" > "View all" to verify. Please stop flaming in public, especially under the pretext of false information. Kind regards

Hello! We're able to answer to this question only and we'll leave the other matter to community discussion. Unfortunately not, version 4.0.0 beta 2 is unstable and not production ready. Beta 3 version is imminent and addresses this instability and various nasty bugs. By the way, if you need OpenVPN, you can reliably use Eddie Android 3.3.0, the stable version, which is rock solid. Eddie 4 beta versions anyway do not add anything relevant to OpenVPN except minor OpenVPN-AirVPN library updates. Kind regards

@2Cents Hello! When a fully qualified domain name (FQDN) has both A (IPv4) and AAAA (IPv6) records, different tools may return or use different addresses when they ask for resolution because they follow different resolution and selection logic. For example, telnet calls the OS resolver which in turn prefers IPv6 or IPv4 according to /etc/gai.conf in Linux; in many distributions by default IPv6 is preferred over IPv4, but you can customize this behavior. We don't think so. Different philosophy. The selected protocol (v4 or v6) is available for ports anyway and you can customize your system preferences. Kind regards

Hello! We are very pleased to inform you that we are taking the necessary steps to completely renovate our infrastructure in the United Kingdom. The current servers will be dismissed and replaced by six 10 Gbit/s servers with newer and much more powerful hardware. Each 10 Gbit/s server will be connected to a full duplex 10 Gbit/s dedicated line and port. Each new server replaces 2.5 current 1 Gbit/s servers in order to increase remarkably the available bandwidth per connected client. At the end of the upgrade, UK will offer a theoretical peak of 60 Gbit/s (full duplex) instead of the current 15 Gbit/s, through adequately powerful servers. According to our plan, three servers will be located in London and three in Manchester. The new servers will start operations around 19-22 February 2026. Current 1 Gbit/s servers will cease operations on the night between 28 February and 01 March (UTC). Any plan changes and/or delays will be communicated promptly. Kind regards & datalove AirVPN Staff

@thetechnerd @MikeHawkener Hello! Some additional related information that may be valuable for you both. When you run OpenVPN: the assigned VPN IP address depends on the daemon of the VPN server you connect to. Each one lives in a separated /24 subnet somewhere inside 10.0.0.0/10 When you run WireGuard: WireGuard lacks any DHCP feature it lives in a unique, gigantic 10.128.0.0/10 subnet throughout the whole AirVPN infrastructure the VPN IP address of each node is linked permanently to the node's key and it is unique in the whole WireGuard address space thus you will have always the same VPN IP address when you use the same key and you don't renew it, no matter which VPN server you connect to Kind regards

Hello! The "range" is specified by mask /32, so it's this single unique address. Yes, it's plausible that some past event flagged the IP address. We don't know the internals of Tailscale but definitely this behavior should be investigated. Why an attempted connection to this specific IP address and why this port? Kind regards

Hello! There's nothing listening to port 54037 on any AirVPN server. We can't see why Tailscale seeks a connection to it, anyway we are sure now that there's no malware there as there's nothing. Probably Malwarebytes behavior comes from some past event or it's yet another over-blocking case. Kind regards

the effective MTU of the tunnel is limited by the smallest MTU anywhere along the path Hello! On our servers the MTU limit is 1420 bytes on a standard Ethernet frame because of IPv6 over IPv4. For PPPoE see also https://www.hitoha.moe/wireguard-mtu-over-pppoe/ So, if you set 1432 bytes MTU for your WireGuard interface, the fragmentation will occur on our servers, not on your side. The upper, actual limit is the lowest MTU in the path, in other words the smallest MTU on the path silently limits the tunnel. The 12 bytes difference may be negligible and most packets will not be fragmented, and you will not see fragmentation on your side, but you could notice a performance hit on upload (upload from you to the server we mean). Kind regards

Hello! Problem solved, can you please try again now? Kind regards

@Zack Hello! The IP address you mention is assigned to AirVPN server Asellus in the Netherlands. Please mention explicitly port Y, we want and must verify what your app (mention the app too if possible) will find on that port, it's important. Kind regards

Hello and thank you for having reported the problem! We are working on it. We will update this thread when the issue is solved. Kind regards

Hello! Please see here: https://airvpn.org/forums/topic/79065-eddie-desktop-apt-repository-signing-key-update/ Kind regards

Hello! Starting from February 1st, 2026, Debian (e.g. Trixie) enforces stricter OpenPGP policies and no longer accepts repository signatures involving SHA1-based certifications. As a result, users may see errors such as: Get:4 http://eddie.website/repository/apt stable InRelease [3,954 B] Err:4 http://eddie.website/repository/apt stable InRelease Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on C181AC89FA667E317F423998513EFC94400D7698 is not bound: No binding signature at time 2025-01-14T13:07:46Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z Warning: OpenPGP signature verification failed: http://eddie.website/repository/apt stable InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on C181AC89FA667E317F423998513EFC94400D7698 is not bound: No binding signature at time 2025-01-14T13:07:46Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z Error: The repository 'http://eddie.website/repository/apt stable InRelease' is not signed. Notice: Updating from such a repository can't be done securely, and is therefore disabled by default. Notice: See apt-secure(8) manpage for repository creation and user configuration details. This was caused by an outdated signing key certification used by the repository. Solution The repository signing key has been regenerated and the repository is now correctly signed again. To restore updates, please re-import the updated maintainer key: curl -fsSL https://eddie.website/repository/keys/eddie_maintainer_gpg.key | sudo tee /usr/share/keyrings/eddie.website-keyring.asc > /dev/null Then run: sudo apt update Sorry for the inconvenience, and thanks for your patience. Kind regards

Hello! Interesting thread indeed, thank you. Our position is close to the EFF position you can read here: https://www.eff.org/deeplinks/2025/08/no-uks-online-safety-act-doesnt-make-children-safer-online We will keep you informed. So far, you probably know well our approach with similar, lower or higher requests from Russia, China and a few other countries, and there's no plan at the moment to change our position. In general, we think that it is impossible that those persons who advance, propose or defend such dangerous laws in so called democracies are in good faith (except in peculiar cases where they suffer from some mental illness or carry a neurological deficit). They have an hidden agenda developed on the myth of pervasive control but more importantly fueled by monetary reward. Yes, that's a motivational reason, maybe almost as strong as monetary reward and votes. Moreover, there is a real possibility that such laws lead on the short run to an increase in support (and therefore votes) which, net of dissent, is positive, even though by tiny tenths of percentage which are anyway not negligible for an embarrassingly inept ruling class that's incapable of developing serious strategies to improve the life of teenagers and children. Their total failure is proven by the official data (England and Whales police records in this case) that show a dramatic rise of sexual offenses against children in the UK in the last 5 years in spite of (and someone could even argue because of) more and more laws allegedly thought to protect children. Where does this 0.1% come from? If you want to stay real please adjust this quota (since 2025, start multiplying that percentage by 250 to begin with). Furthermore, there's no money involved to use Tor, its usage is totally free and well beyond Ofcom abilities to control it. However, it's true that people may find it boring because it's like 10 times slower than a VPN with a decent infrastructure. It would indeed. However, we seriously doubt that the ramshackle British institutions, always short of funds, can surpass the GFW designers and maintainers in efficiency, competence and grandeur of operation. And note that the GFW is routinely bypassed nowadays by the most and least skilled to connect to a wide range of VPNs. Our aggregate data show that this claim is deeply incorrect, at least for AirVPN, if we consider p2p improper usage quantified by DMCA and other warnings. It's not the majority, on the contrary it is a tiny minority. Where does this assumption come from? We would like to assess official stats to compare them with what we gather on the field. Kind regards

Hello! Thanks, we are aware of the problem. Unfortunately the registrar does not allow to change this setting on the authoritative DNS. For a deliberate choice, airvpn.org is one of the very few domain names we operate for which we do not manage directly the metal behind our own authoritative servers. We will anyway remind the provider of the problem as we did in the past and we will consider whether it's appropriate moving the domain name for this problem. Kind regards

@Peter Laanstra Hello! There isn't (and there never was) any throttling policy at all on any AirVPN server. Please test directly from the host (no containers) to quickly discern whether the problem is GlueTun specific or not. Please test different torrent software as well as smaller WireGuard interface MTU (start testing from 1280 bytes). On GlueTun, FIREWALL_VPN_INPUT_PORTS environment variable must be set properly. The fact that you unset it sounds like an error: why do you say that you don't set it to avoid firewall conflicts? This environment variable is read by the container exactly for firewall rules. If the variable is empty, no unsolicited incoming packets will be allowed on tun0 (or any other VPN interface). Please feel free to elaborate. Kind regards

@rpoyner Hello and welcome aboard! We see the problem. First, please make sure you have downloaded Eddie notarized version exclusively from AirVPN web site. Then, you need to avoid app translocation by moving Eddie to the /Applications folder using the Finder app. Once the translocation doesn't take place anymore, please follow this message if any problem persists: https://airvpn.org/forums/topic/70745-eddie-cant-connect-to-any-server/?do=findComment&comment=249545 Kind regards

Hello! No need for MSS clamping when using WireGuard, just modify the MTU if necessary. Since MSS clamping 1. becomes necessary only when you can't modify MTU, 2. needs packet mangling (WireGuard does not expose any option for it) and 3. requires anyway a server side modification, just operate through MTU. (*) In OpenVPN (only when working over UDP), where networking management is a bit different, you can seriously consider the mssfix directive if you have any "fragmentation" problem that causes packet loss and poor performance. mssfix announces to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes. See also OpenVPN manual: https://openvpn.net/community-docs/community-articles/openvpn-2-6-manual.html In Eddie you can add custom directives for OpenVPN in "Preferences" > "OVPN Directives" window. (*) EDIT: there is a special case where MSS clamping becomes necessary with WireGuard too, although it is a consequence of bad PMTUD handling. If an intermediate link doesn’t correctly handle PMTUD (Path MTU Discovery), TCP packets larger than the tunnel MTU may be dropped, and the client will observe hanging connections or stalled downloads, possibly only for certain destination. In this case MSS clamping helps for sure. Kind regards

Hello! Yes, current DDoS / flood unfortunately. Kind regards

Hello! Yes. Server side it is 1420 bytes, so this is your upper limit too. Thus you can test up to 1420 bytes to find the MTU that can provide you with the best performance. Kind regards

Hello! It's a compromise to avoid fragmentation on most networks. https://blog.silvio.cloud/2_WireGuard_and_MTU_MSS You may test different MTU to find the optimal value for your network (the one that can provide you with the best performance). Kind regards

@earthlight Hello! Possible explanation: the listening service does not listen to the VPN interface or is not running. More in details: when the firewall is on, the test packet is silently dropped, so the port tester does not receive a reply and throws error 110 (timeout). When the firewall is off, the attempted connection by the port tester does not time out anymore because the packet is not silently dropped, but the relative connection is reset via TCP RST because the final VPN interface port does not exist and the device kernel is configured to reset connection to non-existing ports. This is consistent with the previous description and explanation. If UPnP works fine when the VPN is off, then it is active on the listening software too. Due to how UPnP works, the listening software will bind to the physical network interface and not to the VPN interface, causing the problem. Please note that if Network Lock is not active you will also suffer traffic leaks outside the VPN tunnel because of UPnP. Please keep UPnP disabled at least on the settings of the listening software. Consider to disable it at router level too as a pre-emptive safety measure if it is not strictly necessary. A checklist you can consider to follow: https://airvpn.org/forums/topic/66388-port-forwarding/?do=findComment&comment=243305 Kind regards

@p1pb0y Hello! We can reach your software from the Internet on the IP address you're currently connected to, port 60798, i.e. your slskd receives the packet and replies accordingly. So your port forwarding configuration, firewall configuration and slskd bind/port setting are all fine and working properly. The logged error must have a cause unrelated to AirVPN port forwarding and also unrelated to the container's firewall. Kind regards

@stallard Hello! At least one error is visible: remote port number differs from local port number. Due to how a torrent program works you must configure matching remote and local ports (for additional details please read the FAQ). Just delete the "local" field of your remote port in your AirVPN account port panel, adjust qBittorrent listening port accordingly, re-start both VPN connection and qBittorrent and follow this checklist: https://airvpn.org/forums/topic/66388-port-forwarding/?tab=comments#comment-243305 Additional tips for the errors you get: Error 111 (connection refused): the connection has been actively reset by the destination system (the client, in this case your system) through a TCP RST Error 110: no reply from the destination system (client), the sent packet has been silently dropped Further information on p2p programs: https://airvpn.org/faq/p2p/ Kind regards