https://airvpn.org/feed/forums/ForumsenWed, 07 Oct 2026 02:45:16 +0000Hello, This is my first time using airvpn or the eddie-ui client. I was able to get this to function on my Debian setup but seem to be struggling with my Arch setup. I'm attempting to set up the "Don't ask for elevation every run" on my operating system and I seem to be unable to have the setting stay. This program was installed via the AUR and is the eddie-ui package. I tried running the program through Sudo in a terminal to see what was happening and got the error "Can't Create Service in this OS" when checking the elevation option in preferences. I am wondering if I am just missing an easy step? I couldn't find any info on the website or the AUR page. I searched the forums and couldn't find any info. Any help is greatly appreciated.Tue, 06 Oct 2026 15:50:28 +0000This is really a recurring issue now and you might have known this already, but this is really affecting the experiences: https://airvpn.org/issues/ Half of the recent issues are US west servers having packet losses, and while the status showing around 30% packet loss, in reality those servers just stop replying completely for a little while.Mon, 05 Oct 2026 08:42:00 +0000Sun, 04 Oct 2026 22:13:12 +0000The IP addresses of ee.vpn.airdns.org, ee2.vpn.airdns.org, and ee3.vpn.airdns.org seem to be random and not Estonian. They are currently resolved to Norwegian and earlier today it was resolved to Netherlands IP addresses of AirVPN. The same thing happens for the IPv6 address entries. Is this normal?Sun, 04 Oct 2026 07:46:13 +0000It's been suffering for over 10 hours now.Sat, 03 Oct 2026 23:57:24 +0000I've been trying to connect to servers located in switzerland in eddie but none of them seem to connect, it checks for DNS and it just fails. Does anyone know why this is happening? for context, i am using eddie-ui on arch linux (CachyOS)Sat, 03 Oct 2026 17:43:15 +0000Basically title. Windows 10 LTSC, Eddie client 2.26.2. Whenever I disconnect from a server and quit Eddie, my internet will never reconnect properly afterwards. Windows 10's network settings shows "No internet access" on my ethernet. No issues getting internet back as soon as I jump back onto Eddie. I haven't experienced this problem previously with other VPNs. I can confirm I do not have network lock in place. Any suggestions? This is a bit of a dealbreaker for me if I'm effectively internet-less whenever I need to turn the VPN off.Fri, 02 Oct 2026 19:25:40 +0000Hello , I can't connect to any server; the list is empty and the button is greyed out. Could someone please help me?Fri, 02 Oct 2026 18:27:14 +0000Dear Sir/Madam, I'm reattaching the log of the problem of "no server available" and the screenshot. Could anyone help me with this? Thanks! BO log.txtFri, 02 Oct 2026 15:26:50 +0000Dear Sir/Madam, Recently, I have been using the Linux version of Eddie, but I found that there is no server available to use. Could you please help with this? Is this a known issue? Thank you! BOThu, 01 Oct 2026 05:14:26 +0000I apologize if this is the incorrect forum for asking this question. Am I allowed to connect from more than one place at a time? e.g. Connecting from my university's WiFi network through my laptop while at the same time having a connection open from my home PC.Wed, 30 Sep 2026 22:45:43 +0000Attached are my system report and log files generated by the Eddie client. I have been using an older macbook for years running severly outdated OS and Eddie software. MacOS: 10.9.5 Eddie version: 2.16.3 This was the last version I was able to get to work on a consistent basis. As of today I no longer populate a server list when attempting to connect. I am unable to launch the newest version of Eddie (26) after installing. It simply does not open. Same issue persists in version 24. I am able to launch versions 18-20, however no servers appear as well, and opening the preference pane crashes the application. Any help would be appreciated; I'm sure my severly outdated everything is the culprit but I am still naively hopeful for any solutions as the service was working for me as recently as 24 hours ago. Eddie_20260930_114122.txt eddiereport.txtWed, 30 Sep 2026 15:52:01 +0000Yeah, just what the title say. I was wondering if we'll have some offers for HalloweenWed, 30 Sep 2026 15:45:17 +0000AirVPN has decent IPv6 support (certainly the best I've seen from VPN providers). However, they still use NAT66 on the server side, and configure tunnels with a single Unique Local Address (ULA) [fd00::/128]. This results in some weird behavior over native IPv6 (with Global Unicast Addresses (GUAs) [2000::/128] in the tunnel): - Clients don't know their real v6 address. - Most software prefers IPv6 GUA over IPv4 over IPv6 ULA, causing IPv4 to be used even if IPv6 is available. - NAT66 can cause some weird behavior as well. My question is why this design was chosen, other than that it mirrors the v4 side 1:1. Given that IPv6 isn't in short supply and it appears that most servers are given at least a /64 from their respective hoster (e. g. M247 and Netrouting B. V.), it should be possible to configure each tunnel with its own global address and skip NAT66. This would make v6 a proper first class citizen, and make the setup way more similar to a non-VPN IPv6 setup, which also uses GUAs everywhere. I can think of a couple of challenges implementing this, but nothing impossible to solve: - Deanonymizing users is potentially easier if they have their own distinct addresses (correlating traffic). But I think this should be easily solvable with OpenVPN by assigning a new v6 on each reconnect. - Wireguard is a bit more difficult as the tunnel IP is baked into the config: Sharing configs across servers wouldn't be possible, and the address would be static. However, Eddie could just regularly rotate addresses and reconfigure them for the proper server.Wed, 30 Sep 2026 09:57:09 +0000Hello everyone! I recently learned about the airvpn. What i like is the tools are all opensource, aligns with my ethos. I even used ipleak back in the day to check my ip info as well. Later i found out that it was made by air's team as well. What truly surprised me is the availability of a forum. It's quite rare and i like it. The website reminds me of archlinux, simple and functional not following every UI/UX trends. I don't have a active plan right now as i joined-in today. Missed the deal by a day, oh well. I am using linux, and earlier with another vpn service i used to get the openvpn files and set it up inside the kde plasma network-manager then setup a firewall rule as kill switch. Is eddie gui a better way to connect to airvpn on archlinux, instead of the above method?Tue, 29 Sep 2026 12:24:04 +0000Hello, I am trying to set up a Jellyfin server for remote access through the VPN to be available outside my local network. Jellyfin is reachable from the Internet through my normal public IP and router port forwarding (tested from my phone using mobile network). With Eddie running and AirVPN connected, the forwarded connection times out. pktmon shows the incoming TCP SYN reaching the VPN interface at 10.184.203.83:8096, but no SYN-ACK is returned. Jellyfin is listening on 0.0.0.0:8096, and Windows Firewall has an inbound TCP/8096 allow rule. I have a Plex media server and qBittorrent running correctly with forwarded ports through AirVPN, but the Jellyfin port is never open and always times out. I set up Jellyfin the same way I did for Plex and qBittorrent, with the applications and the Eddie client running on the same machine, and everything goes through the VPN with network lock. Plex has the 32400 local port, and a randomly assigned external port from AirVPN, it shows as open, and I can access Plex outside of my local network. Jellyfin however, does not work through the VPN despite the same port forwarding set up (8096 local port, random external port). Jellyfin settings match with AirVPN settings, the local port is 8096, and the "public HTTP port number" setting in Jellyfin is set to the same external port in my client area. Any suggestions? Thank you so much in advanceMon, 28 Sep 2026 23:17:06 +0000Hi, I'm having a problem with Eddie 2.26.2 on Fedora 44. Network Lock fails with: Exception: nft issue: exit:1; path:/usr/bin/nft; arg:-f; arg:/var/lib/eddie-vpn/state/netlock_nftables_backup.nft I've already set NftablesTableOwner=no in firewalld. When the error occurs, Eddie removes the firewalld nftables table but then fails to restore/apply the rules. sudo nft list tables is empty afterwards. Reloading firewalld restores it. SELinux is Enforcing. There were some SELinux denials initially, which have been addressed, but there are no new AVC denials when this particular error occurs. System: Fedora 44 Workstation Eddie 2.26.2 firewalld SELinux Enforcing Network Lock: Linux nftables Has anyone encountered this on recent Fedora versions, or is there a known fix? Thanks! [Been trying to resolve this with AI but it's been going in circles for days trying to put in new permissions and nothing is working...]Mon, 28 Sep 2026 08:25:38 +0000Sun, 27 Sep 2026 22:25:47 +0000I recently watched NetworkChuck’s video discussing what a VPN actually hides and, in particular, the idea that using a VPN shifts trust from the ISP to the VPN provider. I use AirVPN, so rather than treating that as a theoretical discussion, I decided to test my own setup and document what I could actually verify. The result turned into a fairly extensive lab exercise and eventually a short technical paper. My test environment was an Ubuntu VM using a manually configured AirVPN WireGuard connection rather than Eddie. I inspected Linux policy routing, captured traffic on both the physical and WireGuard interfaces, tested DNS behaviour, deliberately attempted IPv4 and IPv6 bypasses, forced applications to use the physical interface, tested hard-coded external DNS, stopped the VPN to test failure behaviour, and finally rebooted the VM to verify firewall ordering and persistence. One of the most useful findings actually had nothing to do with an AirVPN failure. My own custom nftables kill switch was broken. I had created a persistent nftables ruleset, but it used interface references that required the airvpn interface to exist when the firewall loaded. At boot, nftables started before WireGuard created that interface, so the firewall service failed. When I stopped WireGuard during testing, the VM silently fell back to its normal VMware NAT route and regained direct Internet access. That was a good reminder that having a security configuration present is not the same as demonstrating that it is operating. I corrected the ruleset to allow it to load before the WireGuard interface exists and then repeated the testing. After the repair, I tested: - IPv4 and IPv6 default routing through AirVPN - DNS visibility inside and outside the WireGuard tunnel - direct queries to the VMware/local DNS resolver - hard-coded DNS to 1.1.1.1 - applications explicitly binding to the physical interface - forced IPv4 and IPv6 escape attempts - WireGuard-down behaviour - reboot persistence - nftables/WireGuard boot ordering The hardened configuration failed closed as intended. The packet captures were particularly interesting. On the AirVPN interface I could plainly see normal DNS queries going to AirVPN’s internal resolver. On the VM’s physical interface, the same activity appeared only as encrypted UDP traffic to the AirVPN WireGuard endpoint. I could not see the individual DNS queries or direct connections to the websites being accessed. A hard-coded query to 1.1.1.1 also behaved as expected: it bypassed AirVPN’s DNS resolver, but did not bypass AirVPN itself. The DNS request still travelled through the WireGuard tunnel. I also queried the AirVPN resolver using CHAOS-class DNS records. version.bind returned "AirVPN DNS" and id.server identified the resolver as: unurgunite.airservers.org The server/network data pointed to the New York Unurgunite infrastructure on tzulo / AS11878. Using Akamai’s whoami.ds.akahelp.net resolver diagnostic, the recursive DNS egress appeared from the same IPv6 /64 as the VPN’s public IPv6 egress, although it was a different address. The response did not include an EDNS Client Subnet value. I also confirmed that the IPv4 WireGuard entry address and the public IPv4 exit address were different. The conclusion I came away with is slightly more precise than simply saying a VPN “hides metadata.” From the local/ISP side, AirVPN successfully hid substantial destination-related metadata. The ISP-side observer could still see the AirVPN endpoint, packet timing, sizes, traffic direction, volume and session duration, but could not directly see the individual DNS queries and destination connections carried inside WireGuard. That brings the investigation back to the trust question. Once traffic reaches the VPN endpoint, AirVPN is necessarily in a privileged network position. HTTPS still protects the application content end-to-end, but the VPN infrastructure is technically positioned to observe destination IPs, AirVPN DNS queries, timing and traffic volume. AirVPN states that it does not retain identifying traffic logs or inspect customer traffic, and a number of the architectural behaviours I could observe were consistent with a privacy-focused design. What I cannot verify externally is the production server-side logging configuration itself. That is the largest remaining evidence gap I identified: I could not find a published independent no-logs/infrastructure audit comparable to those some other VPN providers have commissioned. I would be particularly interested in clarification from AirVPN staff or anyone familiar with the infrastructure on a few points: 1. Does the resolver identified as unurgunite.airservers.org run directly on the same physical VPN host, or is the 10.128.0.1 service presented locally while recursion is handled elsewhere? 2. For the current tzulo New York servers, is the bare-metal hardware AirVPN-owned/colocated, rented dedicated hardware, or another arrangement? 3. Is an independent infrastructure/no-logging audit something AirVPN has considered or plans to pursue? 4. Is my interpretation of the separate entry/exit addressing and DNS architecture accurate, or is there anything important I have misunderstood? I’ve published the complete methodology, evidence, limitations and conclusions here: Paper / DOI: https://doi.org/10.5281/zenodo.22986653 GitHub: https://github.com/Fragmented-Sentinel/what-a-vpn-actually-hides The work is independent and is not affiliated with or sponsored by AirVPN, NetworkChuck, tzulo, or any other organization mentioned in the paper. I’d genuinely welcome technical corrections. The purpose of the exercise was not to prove that AirVPN is “good” or “bad,” but to separate what I could actually verify from what still depends on provider claims and trust.Sun, 27 Sep 2026 06:11:55 +0000Hi I tried to add my public IP to Eddie's routing rule screen so that I can access my public facing jellyfin server while connected to the VPN (my server geo blocks - as soon as I hit it through the VPN, everything is rejected). I am running Eddie on Windows 11. My gateway is 10.0.0.1. Let's say my public IP is 69.69.69.69. My LAN IP is 10.0.0.163. I added my IP (no range) and selected "Outside the VPN tunnel". My server still blocks my traffic. So I run a tracert and see that my traffic is hopping its way back from the VPN server in the country I am connected to. I run "route print 69.69.69.69" =========================================================================== Interface List 31...........................Eddie Tunnel 27...00 11 22 33 44 55 ......Hyper-V Virtual Ethernet Adapter 5...66 77 88 99 00 aa ......Intel(R) Ethernet Connection (2) I219-LM 1...........................Software Loopback Interface 1 =========================================================================== IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 69.69.69.69 255.255.255.255 192.168.0.254 10.0.0.163 35 =========================================================================== Persistent Routes: None Eddie has inserted a rule, but the gateway is wrong. I change my routing table "route CHANGE 69.69.69.69 MASK 255.255.255.255 10.0.0.1 metric 35 if 5" =========================================================================== Interface List 31...........................Eddie Tunnel 27...00 11 22 33 44 55 ......Hyper-V Virtual Ethernet Adapter 5...66 77 88 99 00 aa ......Intel(R) Ethernet Connection (2) I219-LM 1...........................Software Loopback Interface 1 =========================================================================== IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 69.69.69.69 255.255.255.255 10.0.0.1 10.0.0.163 70 =========================================================================== Persistent Routes: None My traffic to my public IP now travels directly, not down the VPN. If you require more info, please let me know.Sat, 26 Sep 2026 09:57:11 +0000Thu, 24 Sep 2026 22:55:26 +0000Right now my eddie client only shows Uppsalla sweden, no other servers anywhere else in the world... Restart, etc does not resolve the issue ThanksThu, 24 Sep 2026 17:46:33 +0000I've been using AirVPN via WireGuard for a long time, but I've recently hit a sort of speed cap and I'm trying to figure out if something changed on the backend routing or if I'm hitting a new local bottleneck. My setup: Hardware: Synology DS920+ NAS (Intel Celeron J4125) Software: Docker, running Gluetun (V3.38 and the latest 3.41.3) Home connection speed: 200 Mbps Down / 200 Mbps Up (Fiber). My problem: Up until September 2nd, I was consistently hitting 180-200 Mbps through the WireGuard tunnel. Since that date, my download speeds have flatlined at exactly ~100 Mbps (around 11.5 to 13 MB/s). To locate the issue, I set up two separate Speedtest trackers in Docker over the past weeks: Direct Internet (bypassing VPN): Consistently holds 202 Mbps (see attached graph). Via AirVPN (Gluetun with WireGuard): Flatlines strictly at ~100 Mbps since early September (see attached graph). Troubleshooting steps I've already taken: Upgraded Gluetun to the absolute latest build to ensure the newest server lists and TCP optimizations are active Tested multiple servers across Germany and The Netherlands Manually set wireguard mtu from 1280 (which was perfect) to 1420 Verified CPU usage on the NAS. Gluetun uses the userspace WireGuard implementation (since Synology DSM lacks kernel support). CPU sits at around 60% during full load. While this is high, the exact same CPU/userspace setup handled 200 Mbps perfectly fine before September 2nd. Does anyone know if there were any routing, load balancing, or WireGuard-specific changes made on the AirVPN servers in early September that could cause this artificial 100 Mbps flatline? Any suggestions on what else I could tweak on my end are appreciatedWed, 23 Sep 2026 09:40:24 +0000I've been for the longest time, even before using AirVPN, struggling to use this site called romhacking. It's basically a repo for translations of roms, and I can otherwise just use something like RetroGameTalk to get ROMs and translations. Though the community there has really taken a nosedive and I don't think it will last very long due to the hostility that's allowed there. I would rather like to get the translations from the source. The problem is, having a site blocking nearly every VPN to get something obviously targeted by patent trolls makes it seem like a honeypot. So I would rather hopefully be able to use this site with a VPN. I did the Routes test and it did not connect a single time. So what's the deal, is it a honeypot? I checked and didn't see anyone else talk about it. https://airvpn.org/routes/?q=https%3A%2F%2Fwww.romhacking.net%2F https://www.romhacking.net/Tue, 22 Sep 2026 07:08:01 +0000