Not connected, Your IP: 216.73.216.49
Online: 39629 users - 525843 Mbit/s total BWAll Activity
This stream auto-updates
- Past hour
-
-
-
-
-
-
-
-
-
-
-
- Today
-
Hi AirVPN Team, Thank you very much for your detailed response and suggestions. I really appreciate the guidance. Following your advice, I tested Gluetun and qBittorrent on a different OS and server, freshly installed, and the first results look very promising — for example, I’m now seeing around 20 MiB/s downloading the Ubuntu ISO. I will continue to explore and test this setup further. I also wanted to note that I initially followed a suggestion from ChatGPT to leave FIREWALL_VPN_INPUT_PORTS unset, but of course, that was a mistake — not everything you read should be taken at face value 😉. I understand that I’ll need to reconfigure everything, but I will be using the new server endpoint: WIREGUARD_ADDRESSES=10.170.0.132/32 WIREGUARD_ENDPOINT=taiyangshou.vpn.airdns.org:1637 WIREGUARD_MTU=1280 SERVER_COUNTRIES=Netherlands FIREWALL_VPN_INPUT_PORTS=xxxx,xxxx,xxxx TZ=Europe/Amsterdam FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24 Thanks again for your support and for clarifying how the firewall rules work — it really helped me pinpoint the issue. Best regards -
.thumb.png.8be84fd39f94c1640ac8c5456fbf3449.png)
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
-
Hi AirVPN team, I discovered that the airvpn.org domain has orphaned DS records in the .org zone that cause DNSSEC validation failures with strict resolvers. The problem: The .org registry has DS records for algorithm 8 (RSA) keys that no longer exist in the DNSKEY set: DS 28066 - Algorithm 8 (RSA) - No matching DNSKEY DS 50944 - Algorithm 8 (RSA) - No matching DNSKEY DS 51959 - Algorithm 13 (ECDSA) - Valid DS 20410 - Algorithm 13 (ECDSA) - Valid Impact: Resolvers with strict DNSSEC validation (e.g., Unbound with harden-algo-downgrade: yes) return SERVFAIL for airvpn.org because they expect DNSKEYs for all algorithms advertised in the DS records. Most public resolvers (Quad9, Cloudflare, Google) handle this gracefully, but users running their own recursive resolvers may be unable to access your website. Fix: Remove the stale DS records (key IDs 28066 and 50944) from the .org registry through your domain registrar. Verification commands: dig airvpn.org DS +short dig airvpn.org DNSKEY +short Thanks for looking into this! -
Hi AirVPN community, I’m experiencing very low torrent speeds (max 10KiB/s) on my NL servers, despite everything being correctly configured. This is unusual because until recently, I was getting high speeds on the same setup. Setup: VPN: AirVPN, WireGuard Client: Gluetun Docker container qBittorrent: binded to interface tun0, optional IP: all addresses Forwarded port: assigned through AirVPN Client Area and verified open (TCP + UDP) MTU: 1420 Firewall settings: FIREWALL_VPN_INPUT_PORTS removed to avoid conflicts Server tried: NL2 and the new NL servers Taiyangshou / Vindemiatrix LAN: 192.168.1.0/24 allowed outbound What I observed: Speedtest in Gluetun container: 170–330 Mbit/s download, 220–260 Mbit/s upload qBittorrent: multiple torrents running with hundreds to thousands of seeds, download stuck at total max 10 KiB/s max, barely any improvement with multiple torrents. Even torrents with many seeds run at e few B/s! Forwarded port is open and correctly set in qBittorrent Everything works fine technically — Gluetun connects, WireGuard establishes, tun0 IP assigned Notes: This behavior is new sinds last week; before this, torrents downloaded at several MB/s on the same NL nodes All technical aspects of port forwarding, MTU, Docker setup have been verified Questions: Is there a new P2P throttling policy on the NL servers? Are there known issues with WireGuard and torrent throughput via Gluetun? Could there be something else limiting torrent speeds that I should check? Any insights or suggestions would be appreciated. Thanks! — Peter
-
Had this Problem yesterday too and found a Workaround. Treat this as a temporary workaround. apt uses "Sequoia PGP" to verify signatures. By default, sqv is configured to accept the SHA1 hash algorithm only until Feb 1st 2026. To Resolve this for a period of Time, reconfigure sqv, copy /usr/share/apt/default-sequoia.config to /etc/crypto-policies/back-ends/apt-sequoia.config, and change the date from 2026.02.01 to 2026.06.01 in the line the Repo should Update again until 2026.06.01, better Solution would be an updated signing Key. -
I’m using a QNAP NAS and have set up AirVPN WireGuard as the default gateway for all network traffic. Everything works fine for outbound connections, but now I need to expose specific container ports to the local network or the internet. I’m concerned that changing any network settings might break the VPN connection. I’ve tried a few port forwarding methods, but they don’t seem to work while WireGuard is active. Has anyone successfully exposed container ports while keeping WireGuard as the default gateway? Any step-by-step instructions or tips would be greatly appreciated. - Yesterday
-
-
@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
-
Hi, since 2026-02-01 my Debian Trixie system can’t update the Eddie APT repo. Debian repos are fine, only eddie.website fails. Error: http://eddie.website/repository/apt stable InRelease sqv: Policy rejected signature because SHA1 is not considered secure since 2026-02-01T00:00:00Z Key: C181AC89FA667E317F423998513EFC94400D7698 Is there an updated repo signing key / re-signed InRelease available (SHA256+), or a recommended fix/workaround until it’s updated? Thanks! -
Cant get airvpn to connect. Attaching the error code line, something to do with wireguard, Im not too savvy at this, any help would be appreciated. E 2026.02.01 08:42:18 - WireGuard > Error: Executable '/private/var/folders/2y/7rnngmrd6fv08b226ryfpksh0000gn/T/AppTranslocation/9BF1287F-A4DC-45F3-8804-E4F4675DFC2B/d/Eddie.app/Contents/MacOS/wireguard-go' not allowed: Not owned by root;
-
-
Reason for Decreased MTU from 1420 to 1320
Staff replied to reversevpn's topic in General & Suggestions
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. Kind regards -
-
- Last week
-
Reason for Decreased MTU from 1420 to 1320
Tommie replied to reversevpn's topic in General & Suggestions
Related to this, when selecting Wireguard in Eddie, is the MSS set to 1320 by default? If not is it recommended to add it to OVPN directives? -
Three new 10 Gbit/s servers available (CA)
iwih2gk replied to Staff's topic in News and Announcement
Its a shame. These were among the absolute fastest (especially Chumukay) when they came on board. They smoked the high powered Chicago servers but they are not reliable for the past week or two. Right across the border in Chicago apparently nobody is attacking those servers. -
I doubt that the processor is the reason however I am using a Ryzen 9 3rd gen on an amd motherboard. Simply putting this here because I notice you guys are running i5 or i7 chips.
-
Hello! Yes, current DDoS / flood unfortunately. Kind regards
-
Reason for Decreased MTU from 1420 to 1320
Staff replied to reversevpn's topic in General & Suggestions
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 -
-
Three new 10 Gbit/s servers available (CA)
Zerolight replied to Staff's topic in News and Announcement
Do you know why these new servers are having high packet loss? -
-
Reason for Decreased MTU from 1420 to 1320
reversevpn replied to reversevpn's topic in General & Suggestions
But if I select a bigger MTU than what you have server-side, won't the effective MTU of the applications running in the tunnel still be constrained to the server MTU? -
Reason for Decreased MTU from 1420 to 1320
Staff replied to reversevpn's topic in General & Suggestions
Hello! It's a compromise to avoid fragmentation on most networks, except PPPoE ones, where smaller 1280 bytes MTU is required. 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 -
Why is the MTU on files generated from AirVPN's config generator just 1320 instead of the normal 1420 for Wireguard? Not saying that this is a bad thing, but just curious.
-
-
-
AirVPN should support DNS over TLS within the VPN tunnels, but currently, this is not the case. Of course, we know that DNS over TLS does not provide any benefit because all DNS traffic goes over the VPN as well (which is also stated in the service description). However, I use Linux, and when the VPN is off, I always keep DoT on. The setting is simply enabled by DNSOverTLS=yes at the resolved.conf file. Because 99% of the time I do not use VPN, I prefer to keep the DoT setting on and not disable it whenever I start a VPN session. But when deploying a VPN session from a WireGuard conf file, the DNS resolution is halted. It is possible to reach the internet through direct IP-address-based connections, but DNS resolution does not work at all. I see that the internal DNS server (10.128.0.1) does respond to the incoming requests at port 853, and I receive the responses, but that is all. Naturally, it is not possible to sniff more deeply into the content of the DNS packets with Wireshark because they are encrypted. But there is a lot of that traffic going back and forth through the tunnel. Do you have any idea what might be wrong? If the DoT setting is disabled, the DNS resolution works inside the tunnel as it should.
-
-
Eddie 2.24.6, very laggy GUI in that its slow to draw the interface, checked mono, there is no updates for it. Eddie works when its connected but the interface is slow. ( think late 90s internet and Jpg downloading effect line by line but a little faster ) Eddie 2.21.8 didn’t have this bug, it was responsive except the server list often jumped around, however when Eddie's interface was open it did stop Kubuntu panel menu from opening. Tried 2.24.6 on mint 23.3 cinnamon on a similar laptop and the bugs here as well. Thankfully I am not the only one to experience this. Eddie 2.24.6 system report is interesting, its slow at first, garbled text, CPU maxes out then eventually the report if compiled but scrolling through it causes the text to break up. Laptops specs : Kubuntu Operating System: Kubuntu 24.04 KDE Plasma Version: 5.27.12 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.13 Kernel Version: 6.8.0-90-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-10210U CPU @ 1.60GHz Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics
-
-
I'm not sure that age verification handling is in the best interest of the service as a whole.
-
@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
