Leaderboard

Hello! We're very glad to inform you that a new 10 Gbit/s full duplex server located in Stockholm, Sweden, is available: Formosa. The AirVPN client will show automatically the new server; if you use any other OpenVPN or WireGuard client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637, 47107 and 51820 UDP for WireGuard. Formosa supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the status as usual in our real time servers monitor , by clicking the server name. Direct link: https://airvpn.org/servers/Formosa Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN Staff

Hello 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?

do not see anything for windows 7 i wish to keep my old computer everything is expensive right now and i would like to use my computer with win7 until it dies thanks in advance

Hola, Just a quick heads-up, as per posts below: And here: This still seems to be a problem on version 2.27.2 on a Windows 11 laptop/PC. Although, my issue isn't as bad as d3adf1sh's. It connects to the server for me after waking from sleep, but sites don't load unless I double click the server from the Eddie UI list and cycle the connection again which fixes the issue. Sometimes, very rarely, it gets stuck on "checking route to ipv4" where I have to completely close Eddie and relaunch. The longer the sleep, the more prevalent of the above issues happening. A short sleep cycle doesn't too often cause any issue when waking the machine. Please address/investigate this issue before releasing a stable version. A clean install with 2.26.2 or 2.27.2 doesn't fix the issue. A minor inconvenience, but an inconvenience nevertheless. Again, I repeat, salivating. Thanks for all the hard work behind the scenes.

I’ve resolved the issue! It turned out to be an internal network issue on the Synology DSM/Docker host side. After conducting the controlled test on my laptop (which reached ~192 Mbps down / ~247 Mbps up on server Phaet), we confirmed AirVPN and the network path were working perfectly. A full reboot of the Synology NAS cleared all networking buffers immediately. Upon rebooting, speed tests within the Docker environment jumped straight back up to ~190 Mbps download and ~176 Mbps upload. Testing across multiple Usenet servers through NZBGet also confirmed full bandwidth restoration. So, AirVPN Server (Phaet) performing flawlessly, the CPU handles everything okay without bottleneck. A simple restart resets the network and docker bridge. Thank you for the quick reply!

Hello! The sustained change you describe deserves investigation, especially since the same setup previously reached 180–200 Mbps. The plateau alone does not establish an imposed bandwidth cap, and we cannot yet link it to a particular server-side change around September 2. Since you have already tried different servers, Gluetun versions and MTUs, we suggest two controlled comparisons before changing more settings: On the NAS, run the direct and VPN tests one after the other, using the same Speedtest application/version and a manually selected Speedtest server ID. Pause other downloads/uploads and record both download and upload speeds. Please confirm whether your two trackers already use the same test server, and verify that the VPN test shows an AirVPN exit IP. If another computer is available, preferably connected by Ethernet to the same router, test AirVPN with a native WireGuard client outside Docker. Use the same AirVPN server, endpoint port and Speedtest destination as the NAS test. Stop the Gluetun tunnel for this comparison, or use a separate AirVPN device key so the two clients do not share a key while connected. If the second computer reaches approximately 200 Mbps while the NAS remains near 100, that would narrow the investigation toward the NAS/container path. If both show the reduction, we should investigate the shared network path and VPN endpoint further. During the NAS test, please also check CPU usage per core and any CPU limit configured for the container. An overall reading of 60% does not rule out one core reaching its limit, although it does not by itself explain why performance changed. Please share the exact AirVPN server names and endpoint ports tested, the Speedtest server ID, download/upload results, and test times with your time zone. Those details will let us correlate your measurements with the relevant servers. Take care not to post your WireGuard private key or full configuration file. Kind regards

Fantastic news! Good to have more servers in the Nordics. Hopefully Baltics would also receive an update soon.

For now...things back to normal. I'll give it about 6 days to stabilize. Unless others have other "dillemas".

This version solved my issues, thanks.

Norway's servers are over 60% most of the day. Can you ship a couple of Sweden's unused servers to Oslo? There's like 5 not being used.

@klimpix Hello! Thank you for testing 2.27.2 after upgrading and rebooting. The updated reports confirm that the issue persists on your system. The new AVC events directly document SELinux denying nft, running in the iptables_t domain, access to /var/lib/eddie-vpn/state/netlock_nftables_backup.nft. Their timestamps match the backup-file errors in Eddie’s log, during both startup recovery and subsequent Network Lock activation attempts. The helper also encounters separate denials involving DNS restoration and cleanup. This gives us clearer evidence of the SELinux access restrictions affecting the persistent-helper configuration. The exact correction still requires investigation into the helper’s execution context and the state files’ SELinux labels and permissions. We will pass these updated reports to the developers for investigation. For now, please continue using password-based elevation, which you reported works with Network Lock, while keeping SELinux enforcing and firewalld enabled. Thank you also for confirming that the tray issue persists with 2.27.2 on Plasma 6.7.5 under Wayland. We will include that information as a separate issue. Kind regards

eddie 2.27.2 works fine for me (debian 13 trixie / KDE / Wayland)

Please do that, for completeness' sake. Close and reopen Eddie in a state which causes the error and try a connection once, then provide a system report:.

eddie 2.27.2 works fine for me

That's understandable. I'm in the midst of going back and forth with staff at AirVPN. They are very responsive and are sincerely trying to figure this out. I'm feeding them logs etc. Yet, From what I gather so far this may not be solved. If they can figure it out I'll be sure to inform you of what we did.

This has been an issue for years. A kvm/qemu guest using NAT (default) to connect to the internet via the host does not work because Eddie network lock prevents it. Can or will AirVpn whitelist libvirt's virtual interfaces by default in Network Lock. Thank you

It works! 😀 Thank you so much for your work! This fix for a persistent bug related to privilege escalation allows me to upgrade directly from version 2.25.1 to version 2.27.2. I can therefore confirm to anyone who is a bit too quick to criticize the eddie-ui user interface that version 2.27.2 poses no obstacle to its use on current operating systems, and that—among many other options—it allows you to choose between 3 WireGuard protocols and more than 50 for OpenVPN! When free software works perfectly, is secure, and offers the end user so much freedom of choice in a graphical interface, we should 👏 thank and encourage the developers rather than criticizing the project for no good reason without contributing improvements in the form of pull requests or forks. 🌻 I hope that other users who encountered similar privilege escalation issues will take as much pleasure as I did in thanking the development team.

Hello AirVPN Support and Development Team, I am writing to report a stability issue regarding a non-deterministic Blue Screen of Death (BSOD) with error code **0x3B (SYSTEM_SERVICE_EXCEPTION)** triggered when disconnecting from a WireGuard tunnel via the Eddie client. Because this crash happens intermittently during the teardown sequence, it strongly indicates a **Race Condition** or **Use-After-Free (UAF)** vulnerability inside the `wireguard.sys` driver wrapper, where memory buffers are accessed after being invalidated by the NDIS subsystem. **System Environment** * **OS:** Windows 10 IoT Enterprise LTSC 2021 (64-bit) * **Build Number:** 19044.7725 * **Eddie Version:** Any version utilizing WireGuard 1.0.0.0 * **WireGuard Driver Version:** WireGuard 1.0.0.0 **Bug Check Details & Stack Trace Summary** * **Bug Check Code:** 0x3B (`SYSTEM_SERVICE_EXCEPTION`) * **Exception Code:** 0xC0000005 (`EXCEPTION_ACCESS_VIOLATION`) * **Faulting Address:** `0xfffff8004f01111e` (Inside `ndis.sys`) * **Trigger Event:** Disconnecting from the WireGuard tunnel using Eddie. * **Key Stack Frames:** Crash manifests inside `ndis!ndisDeviceControlHandler` triggered by concurrent execution paths originating from `wireguard.sys+0x13b02` and `wireguard.sys+0x13844` during an IOCTL-driven shutdown. **Technical Analysis (Race Condition Hypothesis)** The crash signature and call stack point to a synchronization gap during the driver's teardown phase: 1. **Teardown Initiation:** Eddie issues an IOCTL call to halt the adapter. 2. **Memory Invalidation:** NDIS begins freeing `NDIS_MINIPORT_BLOCK` structures and associated packet buffers. 3. **Concurrent Access:** A pending network interrupt or timer event inside `wireguard.sys` simultaneously attempts to process packets using stale pointers. 4. **Violation:** The driver dereferences the invalidated memory, throwing an access violation within `ndis.sys`. **Reproduction Steps** 1. Launch Eddie and connect to any WireGuard endpoint. 2. Maintain the connection for an arbitrary duration. 3. Click **Disconnect**. 4. **Result:** The client intermittently crashes with BSOD 0x3B instead of executing a clean disconnect. The failure is purely stochastic and independent of network traffic load. **Troubleshooting Performed** * Fast Startup: Disabled. * Clean Install: Performed complete purges of Eddie and residual `wireguard.sys` drivers, followed by clean reinstalls. The issue persists. * Traffic Load: Tested under both idle and high-throughput states; failures occur uniformly, confirming a state-dependent synchronization bug rather than a load-dependent fault. **Impact & Request** This issue undermines system stability on Windows 10 IoT LTSC environments. Since the official WireGuard for Windows client utilizes `Wintun.sys` (which manages adapter concurrency and teardown safely in user-space/TUN architecture), the legacy `wireguard.sys` wrapper appears to lack robust reference counting or synchronization primitives (such as proper spinlock implementation) during NDIS miniport halts. Could you please clarify: * Are you aware of this specific race condition in `wireguard.sys`, and is there an updated build or fix available? * Are there plans to transition Eddie toward native `Wintun.sys` utilization to bypass these kernel-level concurrency constraints? Thank you for your time and assistance in analyzing this behavior. A full kernel memory dump (`MEMORY.DMP`) is attached to this message. 091326-9562-01.dmp

@Riesengebirge the answer is here : I didn't find any other solution. I guess you can find where is the eddie profile in windows 10 blablabla and then delete it. Or you can try the 2.27 (beta) version.

Your list of filter lists is a copy from uBlock Origin's predefined filter lists, and all of them and most of their variants are integrated into OISD Full, so please use that if you need all the lists you mentioned. Same with OISD NSFW for NSFW content, those two lists are really, really good. You hit the nail on the head. That's why the most popular implementations and suggestions are not those smaller lists, but the projects summarizing/deduplicating them: OISD, Hagezi, Energized (not sure if stlll alive, that one) and others. OISD and Hagezi have been the cornerstone lists in my local network for years now with one false positive a year, maybe. Every profile choice needs a separate (curated) list for that filtering purpose. Currently, AirVPN offers a curated ads/tracking, two security, a dating, a gambling and a porn list. Users can then choose to combine them with any other lists to have their own individual, custom filter – for all devices or just one, if they so choose. An arbitrary definition of profiles takes that freedom away: Some see ads, tracking and privacy as the baseline, some only the most intrusive ads or most known ad domains. If you differ between ads and tracking, chances are you will be tracked without ads being shown. Users should just combine the offered lists to have their own custom definition of strict.

Yes, I understand from researching this that some other VPN's suffer the same issues. It seems when a VPN rewrites the firewall it overwrites the rules libvirt needs to make the NAT connection or maintain the same if the NAT was established before the vpn was was put into service with a network lock enabled.

I got the same error about mscorlib.dll, however I am using Arch with paru instead of yay. By default I have paru build in a chroot, however when I told it not to use a chroot (paru --nochroot eddie-ui) it now runs correctly. Yay doesn't have chroot support so it also worked without any configuration. I am not sure what the difference is between chroot and non-chroot building, but it would be nice to be able to use chroot when building. Regardless of how I build it, the file /usr/lib/mscorlib.dll doesn't exist, so maybe the chroot build thinks it exists for some reason.

Hello! @nwlyoc A few suggestions to improve the software, can you please check them and verify whether the detected problems are real? 1. IMPORTANT. The sudo password is piped through xargs, which turns it into a command-line argument for printf. This can make the password temporarily visible through /proc/<pid>/cmdline or process-monitoring tools. xargs can be removed and the password passed directly to sudo -S via stdin. 2. The AirVPN API key is stored in plaintext inside vpncontrol.conf, while the installation procedure does not enforce restrictive permissions. On a multi-user system, the file could therefore remain readable by other local users. The configuration directory should be 0700 and the file containing the API key 0600. 3. IMPORTANT. The nftables ruleset adds ip saddr to the whitelist after an allowed DNS query and later accepts packets whose ip saddr matches that set. In the OUTPUT chain, ip saddr can be the host's own local address, so this can unintentionally allow subsequent outbound IPv4 traffic and defeat the Network Lock. The whitelist must operate on destination addresses ip daddr, not source addresses. Kind regards

I'll wake this topic up again regarding libvirt. I have the problem with kvm qemu virtual machines not being able to connect due to the Eddie lock not letting the guest machine connect via NAT. It is suspected the issue lies in the way Eddie uses nft and libvert use ip-tables. I tried setting Eddie to Iptables-legacy then closed Eddie and opened it again, but the problem persisted. Should I have rebooted or logged out of the host machine after making the change to iptables-legacy?

I probably started before you were born but know that I have 4 times faster upload since I subscribed here.

Hello! A few flood attacks caused various problems throughout August but the main problem since one or two weeks ago is the uplink capacity in our opinion. We were expecting maintenance operation in the Zurich DC to increase uplink capacity and improve access switch redundancy by adding a second switch to the rack between Aug 31 and Sep 1, but it was unfortunately re-scheduled to Sep 8. We will evaluate whether the added capacity will be enough to resolve the problems and we will act accordingly. Kind regards

Still waiting on return of Lithuanian servers, or even high bandwidth (20gbps) ones in any Baltic country.

Last time this came up:In short, try building that package in a clean chroot. Usually, it indicates that some package was built against an older version of Mono. CachyOS keeps coming up as the culprit from time to time as it provides a repo with prebuilt AUR packages, some of which are not meant to be distributed like that, but Manjaro is not without its problems, either.

Hello! We're very glad to inform you that a new 10 Gbit/s full duplex server located in Los Angeles, California, is available: Flegetonte. The AirVPN client will show automatically the new server; if you use any other OpenVPN or WireGuard client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637, 47107 and 51820 UDP for WireGuard. Flegetonte supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the status as usual in our real time servers monitor , by clicking the server name. Direct link: https://airvpn.org/servers/Flegetonte Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN Staff

I try switching servers but I usually get the same slow speed. Right now (it's 21:00 local time), it's particularly slow. I was connected to Matar, the best available server according to Eddie, and the download speed from a kDrive was under 200KB/s. I switched to "Crater", same result. I switched to Albali Uppsala Sweden, this time the download speed stalled under 50KB/s! Also, this happens on both of my systems. A few months ago, the speed were good, sometimes very fast. I can't understand what happened.

Hello, I'm curious what causes the brief 1-2 periods of packet loss in the 4 Los Angeles servers. It seems like half of the "issues history" page is just these 4 servers. I have my config set to Los Angeles and Fremont, and it almost always inevitably ends up stable on the Fremont server due to the LA health check problems.

You actually have set a speed limit of 10 kb/s, might have been by accident of clicking that little speedometer icon OMG that's right @ag999. LMAO! Just tested it and was the same. Now I know. I did not know this was a feature to click on that speedometer. 🙈 Hope it helps others... Anyway, I did some CLI speedtests in my gluetun conainer (I have a 1Gbit connection). I think it is what it is... / # speedtest Retrieving speedtest.net configuration... Testing from Global Layer (213.152.161.181)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Qonnected B.V. (Amsterdam) [16.73 km]: 11.237 ms Testing download speed................................................................................ Download: 60.14 Mbit/s Testing upload speed...................................................................................................... Upload: 44.11 Mbit/s / # speedtest Retrieving speedtest.net configuration... Testing from Global Layer (213.152.161.181)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Qonnected B.V. (Amsterdam) [16.73 km]: 12.603 ms Testing download speed................................................................................ Download: 28.36 Mbit/s Testing upload speed...................................................................................................... Upload: 25.01 Mbit/s

You actually have set a speed limit of 10 kb/s, might have been by accident of clicking that little speedometer icon

With IPv6 allowing practically infinite IPs it should be possible to assign a dedicated IPv6 address to each connection, allowing incoming connections to any port to be forwarded. This would be a great way to circumvent the port forwarding restrictions on IPv4 that exist because multiple clients have to share the same exit IP, and I think would make for a nice optional feature.

May I request the addition of 10Gbps Tokyo and Singapore servers? Thank you.

+1

Man im tempted to buy more time but I think im covered

Dark mode on this site would be nice. Strange that there is no dark theme aleready? I use a huge screen and its like flood-lights when i open this page lol opening airvpn.org:

We have kept the OP message to show the pervasiveness of the PRC's propaganda lackeys. We consider Taiwan (Republic of China) to be independent and autonomous from the PRC (People's Republic of China), as it is in fact. ipleak uses MaxMind and IANA databases to display results, and we are pleased that these are aligned with an anti-imperialist and democratic vision that is clearly unpalatable to the dictatorial regime of the PRC, which sees it as an obstacle to its expansionist ambitions.

Yes I agree

Staying connected now already means they are already associated for months with the same IP address. They are no more exposed over time in that scenario than they are already today. Telling users apart on the exit side of a VPN is a trivial task for almost any use case. You can visit https://www.amiunique.org/ with a fresh install of Tor browser and still get fingerprinted down to the individual level. The real benefit of a commercial VPN is the disconnect between input and exit, not the dubious "herd safety" that one thinks might be there. Yes, I mentioned already this is more difficult to accomplish in Wireguard. It rises from the trivial "few hours to get a proof of concept" it is now with OpenVPN to the more substantial "a couple days work" with Wireguard. It would be easier to do in Wireguard with an OnConnect style hook patched in. The good news is such a patch would not be needed client-side. Client-side nothing changes. As I think about it, it's also probably doable with some clever use of libnetfilter_queue and nft queues. Indeed. But what a great selling point for IPv6. And for this service. I see very little anonymity/privacy difference (positive or negative) in implementing this idea. Already today every IP on a v6 /64 is essentially lumped together as a collective whole anyway, since /64's are handed out like candy to everyone. A lot of places log, filter, and block based only on the /64 prefix and just ignore the bottom 64-bits entirely. So giving out unique addresses from that won't really make anyone more or less anonymous and it probably won't circumvent any blocking of this VPN that's in place now or in the future. But what it does buy is the ability to listen on anything without port forwarding. Listening on anything gives you access to everything. So this is a great selling feature for people who implement a VPN at the home-router or VPS level. The idea that NAT-PMP and UPnP will Just Work™ after implementing this would, I think, be very attractive. Something to think about at least.

A dynamic 1:1 exit address assigned on a per-connection basis from each server's /64 pool would be a great solution to this. In fact, it's probably doable now with some clever scripting and an nft map where the permanent fdxx:: for each customer is mapped on a per connection basis with an address from the server's /64 routable pool. In wireguard this might be a little ugly today, being that wireguard has no real "connection" state, so you'd want to hook based on going from "no recent handshake" to "recent handshake". So as I think about it it's probably not feasible with scripting alone. But I don't think it would be all that difficult to hardcode a hook that gets called whenever a connection goes from having a late (or non-existant) last handshake to a recent handshake. Handshakes occur every 120-ish seconds, so you could code it for 150 seconds. I'm not suggesting this in the immediate-term, but it's not something that needs to be a "someday...wouldn't it be nice" event either. In OpenVPN it would be a lot easier being that it does have a client-connect script hook, and is probably something that could have a proof-of-concept with a couple hours work. Or just use DHCP to do the same thing. You wouldn't even have to keep track of IP addresses. Each one can be disposable one-time use. You could start at the server /64's ::1 and count up to FFFF:FFFF:FFFF:FFFF for each connection and not run out until, oh, Andromeda collides with the Milky Way.

Yes more norwegian servers would be nice. I was going to make the same suggestion. Also one more server in estonia would be great. Good speeds from Alruba when its not at capacity

Hello! The paramount IPv6 privacy problem, which was considered by many as a critical or fatal flaw compromising adoption and usage, has been resolved through privacy extensions: https://www.internetsociety.org/resources/deploy360/2014/privacy-extensions-for-ipv6-slaac/ Nowadays, ten years after that article by The Internet Society and 17 (seventeen) years after RFC 4941 virtually all widespread systems have finally adopted the very much needed privacy extensions. However, one bad apple may compromise the whole local network. See for example this paper: https://arxiv.org/abs/2203.08946 where the authors show how a single device at home that encodes its MAC address into the IPv6 address can be utilized as a tracking identifier for the entire end-user prefix. Therefore, it is good practice to verify with care every and each device and making sure that their Operating Systems implement the privacy extensions. Other than that, we can't see any serious hindrance to adopt IPv6 as far as it pertains to privacy. Furthermore, in AirVPN we picked an unorthodox approach, i.e. we implemented NAT66 with ULA, as it is one of those rare cases where it comes handy to strengthen the anonymity layer (a thoughtful analysis of the pros and cons of NAT in IPv6 can be found in the following article for example https://blogs.infoblox.com/ipv6-coe/you-thought-there-was-no-nat-for-ipv6-but-nat-still-exists/ while a pragmatic approach is here: https://blog.ipspace.net/2013/09/to-ula-or-not-to-ula-thats-question/). Switching from privacy to security, probably an informed choice can start by reading this article, that also includes other precious sources, again by the Internet Society: https://www.internetsociety.org/deploy360/ipv6/security/faq/ Kind regards

Do you think you should disable 5 GHz WiFi? Do you think you should disable LTE on your phone? Do you think you should disable all USB-C ports? That's the kind of question it is. The answer to all of them is another question: Why would you ever think about preferring older tech if you've got the option to use newer? And no, I don't want to hear arguments like "I disable 5G because of radiation" – the only thing irradiated is that thought, irradiated by some web page, probably served on a v4 IP address over an ADSL line (which, interestingly, emits more radiation and consumes more power than a Fiber line and associated infrastructure). v4 is ossified and does not meet today's needs. It's a pain to maintain for people, organizations and everyone and everything in between. The only reason people still use and maintain it is purely out of conveniece. But that's humanity for you, I guess.. Now, let's analyze this, taking the aforementioned convenience into consideration specifically.. Disabling v6 won't do a thing to your connectivity. There are tiny, tiny freckles in the face of the whole internet talking v6 only, but if you disable v4, half of that face will be gone. If you leave both enabled, v6 will be preferred, but through Happy Eyeballs v4 will be tried and preferred itself if v6 was too slow. Doesn't really up the connectivity, it's just a temporary measure while we all transition to v6, but ooh, the convenience.. and also because there are ISPs in the world still assigning v4 only to their customers. Honestly, v6 is almost 30 years old itself and some parts of the world still treat it as the New Hot Shit™. Talking configuration, OpenVPN's config options differ from those for v4 (--route != --route-ipv6, for example), so for some use cases you will find v4 easier to configure than v6. For Wireguard, I suppose it doesn't really matter since it was written in a time where v6 was actually in use (while OpenVPN was written when Tyrannosaurus Rex was still the apex predator, I believe. Small dino hacking away at a miniature keyboard at the foot of some volcano or the other; times were as wild as this imagined picture). v4's got the leg up here because four numbers up to 255 delimited by a dot are both easier to write and easier to memorize than eight freaking groups of four hexadecimals in each, so you are dependent on DNS more or less.. (as if you're not dependent on DNS with v4, though; care to test yourself? Just name all v4 addresses of, I don't know, YouTube. Oh, do I spot you nslookuping youtube.com? You've fallen into my trap.) So, should you disable v6? No, you should not. You are effectively prolonging the life of v4 by this; a protocol which is finished, both in the literal (as in, finished being developed) and metaphorical (as in, End Of Life) way. If you are insistent on not using v6, pay attention to your config and simply route it via VPN as you would route v4. The OpenVPN v6 options might not have absolute parity with v4, but OpenVPN does route v6 just fine. Route them both. And if you've got v6, connect via v6 (barring the case of v6 availability but the Providers' Piss-Poor Performance® of it; then you are excused if you formally complain to your ISP. It's not even a joke: Complain about shabby v6 treatment of your service providers, to those service providers). Thank you for reading my sermon. May the Elders of the Internet protect you. Or the Admins of the AirVPN, whichever is closer to your heart.

It would seem that this actually fixed both issues (for the DNS leak, I can only say so for just one of the tested WiFi networks on which the leak existed). Thanks.

You didn't explicitly mention that you can't access the app. I took the whole thread as being curious about why the second dialog appears. If that's the case, you need to delete the eddie.profile file in your user directory. It's in /Users/(username)/.config/eddie/.

AIRVPN DOES NOT RECOGNIZE ANYMORE VERISIGN, AFILIAS AND ICANN AUTHORITY. OUR COMMITMENT AGAINST UNITED STATES OF AMERICA UNFAIR AND ILLEGAL DOMAIN NAMES SEIZURES. The United States of America authorities have been performing domain names seizures since the end of 2010. The seizures have been performed against perfectly legal web-sites and/or against web-sites outside US jurisdiction. Administrators of some of those web-sites had been previously acquitted of any charge by courts in the European Union. The domain name seizures affect the world wide web in its entirety since they are performed bypassing the original registrar and forcing VeriSign and Afilias (american companies which administer TLDs like .org, .net, .info and .com) to transfer the domain name to USA authorities property. No proper judicial overview is guaranteed during the seizure. Given all of the above, we repute that these acts: - are a violation of EU citizens fundamental rights, as enshrined in the European Convention on Human Rights; - are an attack against the Internet infrastructure and the cyberspace; - are a strong hint which shows that decision capacities of USA Department of Justice and ICE are severely impaired; and therefore from now on AirVPN does not recognize VeriSign, Afilias and/or ICANN authority over domain names. AirVPN refuses to resolve "seized" domain names to the IP address designated by USA authorities, allowing normal access to the original servers' websites / legitimate Ip addresses. In order to fulfil the objective, we have put in place an experimental service which is already working fine. If you find anomalies, please let us know, the system will surely improve in time. Kind regards AirVPN admins

Hello ! 1) Functional port forwarding is necessary for torrents to work properly. Many users don't have it set up correctly, meaning if you also don't have it set up correctly you won't be able to connect to them... leaving only the overloaded connectable ones. 1a) To do so, first FIND a free port here in the Forwarding section: https://airvpn.org/ports/ 1b) Then use that port in your client - in qBitTorrent - Tools -> Options -> Connection - Set PORT, and make sure you uncheck Use UPnP !!!! (not used for VPN!) and uncheck Use different ports... you want to keep the same port all the time! 2) Speed depends on what are you torrenting - In general any "public" stuff is going to be slow or very slow. Some specialized private trackers however have users with high-speed connections, dedicated seedboxes (servers) and such, and they are interested in ever-increasing that precious ratio so they are not going to throttle their speed. If you get only 100kbps on some random TPB torrent, don't complain about VPN, it's not going to help 3) Make sure Encryption is enabled in your client, even if VPN itself encrypts. If you don't have encryption enabled, it might be that your peers are being throttled, even if you're not ! Remember, this is a 'group dance', it's not just about your speed and your internet. 4) Simply pick another server ! You might have chosen one which is closer to you, but perhaps your PEERS are somewhere else. Generally choosing a server in West Europe ( Netherlands, Germany, UK ) will result in the best speeds for torrents. 5) Have a fast computer ! I've seen so many times that people complain about torrent speeds on a slow laptop with an extremely fragmented harddisk. You're giving that poor computer so much work it can't handle. Use tools like Ccleaner to cleanup garbage files and Defraggler to keep it defragmented (skip this part for SSD's, but cleaning up files is still good !) My torrent machine is a modern Quad-Core Intel overclocked @ 4Ghz with a Raid0 array of 2 HDD's as the "dump" (where things download). It can easily take 1gbps of speed (not available at my current location due to ISP limitations, but I had 1gbps internet before). Never had any problems with it not able to maintain a speed, even for huge tens-of-gigabytes torrents. Hope these help Yarr matey !

The United States is an enemy of the Internet. More and more our technology and communications are captured illegaly and stored for many years and then used against us in court. The government seems to sincerely believe that it owns the Internet and regulary hacks into foreign servers to retrieve data, seizes domain names, etc. and any citizen who can be considered a hacker under broad laws will be thrown in prison. My warning as a US citizen is to watch out, encrypt, keep everything secure, keep data offshore, and avoid any US-influenced entities such as ICANN. Thank you AirVPN for the great continued service. I've been using multiple VPN connections almost constantly for the past year everywhere and as far as I can see that will continue