Not connected, Your IP: 216.73.217.121
Online: 45801 users - 593350 Mbit/s total BWAll Activity
This stream auto-updates
- Past hour
-
-
-
-
-
-
-
-
-
-
- Yesterday
-
All US west servers keep having issues
SurprisedItWorks replied to haruka_ff's topic in Troubleshooting and Problems
Quick note: I've been so frustrated the past few months with Los Angeles servers, especially since they are the US "best" so often, that I actually coded up a tiny daemon for my routers to have them detect those servers and if found, automatically switch OpenVPN to a non-L.A. server. The Los Angeles servers have been so bad that I'm not comfortable leaving family to deal with them all day. In other words, this issue isn't about one user at one particular time. There's a bigger problem here. Broader observation: Before the huge influx of former Mullvad users, I changed OpenVPN servers by hand a few times a year. Now it's generally every day and often multiple times daily, no matter where (in the US, where I generally "am") those servers are, because the delays and stoppages become intolerable. I don't know if it's about flood attacks, datacenter issues, or simply too many users. I love Air for its features, transparency, and strong support, but this downside is real. (I'm on OpenVPN 2.7.5 with DCO on three router models, all running a recent dd-wrt build using a linux 6.12 kernel. Multiple Air accounts are involved.) -
.thumb.png.8be84fd39f94c1640ac8c5456fbf3449.png)
All US west servers keep having issues
Staff replied to haruka_ff's topic in Troubleshooting and Problems
Hello! Thank you, that clarification helps. Since your tunnel endpoint is reached over IPv4, the recurring IPv6 pattern we mentioned does not explain your experience. We see ICMPv4 nearby packet-loss reports for the servers you named: Sarin at about 07:20 UTC and Revati at about 07:58 UTC. These are close to, but do not exactly match, the 07:35 UTC time you reported. They come from distributed monitoring probes, so they cannot confirm what happened on your particular route. Could you tell us which VPN protocol and client you use, and whether the VPN connection itself disconnected or stayed connected while traffic stopped? If available, please also share the connection log covering a few minutes around 07:35 UTC, with any keys or credentials removed. This should help us compare the event with the server and network records. Kind regards -
Staff reacted to a post in a topic:
SOLVED - 10.4.0.1 DNS issue with WireGuard / OPNsense / NL servers ...
-
All US west servers keep having issues
haruka_ff replied to haruka_ff's topic in Troubleshooting and Problems
Hi, I connect via IPv4 to mainly Sarin and Revati servers though. the last issue I had was to Revati, around 07:35 UTC. -
Hi, wow, thank you very much for the incredibly fast and detailed response! CASE CLOSED. That clears things up completely. I will use 10.128.0.1 as the DNS server and DNAT target for my WireGuard setup from now on. Also, thank you for acknowledging that the current Specs page is somewhat misleading regarding 10.4.0.1 and WireGuard. Looking forward to the updated documentation. I also appreciate the additional explanation regarding DNS leak prevention and making sure DNS traffic cannot fall back to WAN. My OPNsense rules are already designed around that principle. Overall very happy with the support and I'll happily renew for another three years when the Cyber Deal becomes available again. 🙂 Cheers! -
All US west servers keep having issues
Staff replied to haruka_ff's topic in Troubleshooting and Problems
Hello! We checked our infrastructure monitoring data and can confirm recurring connectivity issues, concentrated on our five Los Angeles servers, not on all West Coast servers though. The recorded issues predominantly affect IPv6. If your VPN tunnel is established over IPv6, it is indeed very likely that these incidents explain the temporary complete loss of connectivity you describe. The packet-loss percentage on the status page reflects results from multiple monitoring locations. A reading of around 30% does not mean that every connection loses 30% of its packets: connectivity from a particular network can fail completely while other paths remain available. Is your VPN tunnel established over IPv4 or IPv6? We mean the address used to connect to the VPN server, rather than whether you access IPv6 destinations inside the tunnel. Please also provide the affected server names and, if possible, an approximate incident time with your time zone, so we can correlate your experience with our monitoring. We apologize for the recurring IPv6 interruptions and we will open a request for investigation with the provider. Kind regards -
Hello! For AirVPN WireGuard connections, the IPv4 gateway and DNS server address is 10.128.0.1. WireGuard uses a single IPv4 subnet, and this address remains the same regardless of which AirVPN server you connect to. Please keep 10.128.0.1 as your DNS DNAT target. 10.4.0.1 is an OpenVPN DNS address, and its availability through some WireGuard connections should not be relied upon. Your observation that it works through a German endpoint does not change the address to use with WireGuard. The reported difference alone does not establish a DNS outage on Dutch servers. You are also right about the documentation: our Specs page describes 10.4.0.1 as reachable from any virtual subnet without explicitly restricting that statement to OpenVPN. That wording is misleading for WireGuard users, and we apologize for the confusion. We will assess the situation and either clarify the Specs page or make 10.4.0.1 consistently reachable for DNS queries through WireGuard on all servers (not recommended anyway, see below). In any case, we recommend using the VPN gateway address as the DNS server address, as AirVPN supports this configuration, with both OpenVPN and WireGuard. We recommend using 10.128.0.1 for WireGuard DNS and ensuring that DNS traffic can only leave through the VPN tunnel. Route-injection attacks on hostile networks can otherwise divert DNS queries outside the tunnel, exposing the requested domain names and potentially enabling forged DNS replies. This class of attack can also affect WireGuard deployments, depending on the operating system’s routing and firewall configuration. For your OPNsense setup, redirect the selected clients’ DNS traffic, both UDP and TCP port 53, to 10.128.0.1, ensuring that the redirected traffic is routed through the WireGuard tunnel. Firewall rules should prevent those clients from falling back to WAN when the VPN is unavailable. Port 53 redirection alone does not control applications using DNS over HTTPS or DNS over TLS. Your interpretation of the successful dig @10.4.0.1 test with DNAT targeting 10.128.0.1 is correct: it does not demonstrate that 10.4.0.1 itself answered. Kind regards
-
This 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.
- Last week
-
Hi, I am using AirVPN directly on an OPNsense firewall as a WireGuard gateway. My setup is roughly as follows: OPNsense establishes the AirVPN WireGuard tunnel. The WireGuard endpoint is configured using: nl.vpn.airdns.org (213.152.161.137:1637) Selected VLANs / networks / hosts are policy-routed through the AirVPN gateway using OPNsense firewall rules. Other networks continue to use the normal WAN gateway. The client used for the tests below is an Arch Linux container. Client IP: 192.168.25.204 Default gateway and DNS server of that client: 192.168.25.1 DNS setup The VPN clients do not use the AirVPN DNS server directly as their configured DNS server. Instead, they use the OPNsense firewall as both their default gateway and DNS server. On OPNsense I have a DNAT / port-forward rule which redirects DNS traffic from these VPN clients to the AirVPN DNS server. Depending on the configuration I am testing, the DNAT target is either 10.4.0.1 or 10.128.0.1. The normal DNS flow is: VPN client 192.168.25.204 | | DNS query v OPNsense 192.168.25.1 | | DNAT v AirVPN DNS 10.4.0.1 or 10.128.0.1 | v AirVPN WireGuard gateway I originally used 10.4.0.1 as the AirVPN DNS server because it is documented as an AirVPN DNS resolver. Today I noticed that DNS queries are no longer answered when 10.4.0.1 is used as the DNAT target while the WireGuard tunnel is connected to nl.vpn.airdns.org. The OPNsense firewall still passes the traffic correctly and the affected clients are otherwise routed through the AirVPN gateway normally. 10.128.0.1 works perfectly as both the DNAT target and AirVPN DNS server with the same nl.vpn.airdns.org setup. Also, when I switch the WireGuard endpoint to de.vpn.airdns.org and use 10.4.0.1 as the DNAT target, DNS works correctly again. So the behaviour is currently: WireGuard endpoint = nl.vpn.airdns.org (213.152.161.137:1637) DNS DNAT target = 10.4.0.1 -> DNS queries time out WireGuard endpoint = nl.vpn.airdns.org (213.152.161.137:1637) DNS DNAT target = 10.128.0.1 -> DNS works perfectly WireGuard endpoint = de.vpn.airdns.org DNS DNAT target = 10.4.0.1 -> DNS works correctly Additional tests From the Arch Linux client, the route towards 10.4.0.1 is: # ip route get 10.4.0.1 10.4.0.1 via 192.168.25.1 dev eth0 src 192.168.25.204 uid 0 cache When the DNS DNAT target is set to 10.4.0.1, a direct UDP query fails: # dig @10.4.0.1 cloudflare.com ;; communications error to 10.4.0.1#53: timed out ;; communications error to 10.4.0.1#53: timed out ;; communications error to 10.4.0.1#53: timed out ; <<>> DiG 9.20.29 <<>> @10.4.0.1 cloudflare.com ; (1 server found) ;; global options: +cmd ;; no servers could be reached TCP fails as well: # dig +tcp @10.4.0.1 cloudflare.com ;; Connection to 10.4.0.1#53(10.4.0.1) for cloudflare.com failed: timed out. ;; no servers could be reached For comparison, when I change the OPNsense DNAT target to 10.128.0.1, DNS resolution works immediately. I also tested: # dig @10.4.0.1 cloudflare.com while the DNAT target was 10.128.0.1, and received a successful response. However, because the OPNsense DNAT rule redirects DNS traffic from these clients, I realize that this test may actually have been redirected to 10.128.0.1. Therefore I do not consider this proof that 10.4.0.1 itself was reachable in that test. Questions Is 10.4.0.1 still supposed to be reachable and usable as a DNS resolver from current AirVPN WireGuard connections? Or is 10.128.0.1 now the recommended DNS server for WireGuard connections? Is there currently any known issue with 10.4.0.1 when connected through Dutch servers / nl.vpn.airdns.org? Since the exact same OPNsense DNAT setup works perfectly when using 10.128.0.1 as the target, I assume that the DNAT mechanism itself is working correctly. Is there any known reason why 10.4.0.1 specifically would behave differently as the DNAT target? Is there any recommended OPNsense / pfSense configuration for forcing selected VPN clients to use AirVPN DNS while avoiding DNS leaks? If useful, I can also provide: OPNsense WireGuard configuration firewall / policy-routing rules NAT / port-forward rules packet captures from the AirVPN interface wg show output Thanks!
-
-
Seeing the same behavior here as well. it'll get to check for dns fails 4-5 times then tries to restart. -
@1234asdfghjkl Hello! Alruba is now up. We have not been informed about the exact problem it suffered but we see that it's up and working fine. Kind regards
-
Makes sense, thanks! -
@1234asdfghjkl Hello! The server is completely unreachable. Even IPMI and KVM power cycle don't work. We're waiting for datacenter technicians feedback. We will keep you posted. Kind regards
-
Hello, This is expected behavior: our server in Estonia is currently down, so the domain name temporarily resolves to IP addresses of AirVPN servers in other countries. This fallback allows users with configuration files for Estonia to continue connecting while the Estonian server is unavailable. Kind regards
-
The 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?
-
It's been suffering for over 10 hours now.
-
-
-
-
I'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) -
-
-
Feature Request: Native IPv6 support (no NAT)
Divinity3372 replied to Divinity3372's topic in General & Suggestions
Thanks, that reasoning makes sense. I guess another solution would be to use GUAs on the tunnel, and then NAT those GUAs on the VPN server. That would fix the routing precedence issues (as most software prefers IPv6 GUAs over IPv4 over IPv6 ULAs). Cloudflare Warp uses this solution. However, it's not without its own issues as well, as most software expects GUAs to never ever NAT (I think WebRTC can have issues with this approach). Other than that, I've been told that OVPN uses ULAs + NAT66 for Wireguard, and GUAs in the tunnel for OpenVPN (without NAT). However, I'm too cheap to rent their services for a month to confirm (12€ a month!). They're the only VPN provider I'm aware of actually implementing GUAs in the tunnel, without NAT66. I also want to repeat that this is mostly critique of technicalities, AirVPN has been rock solid ever since I've switched (v4 and v6). Greetings, Divinity3372 -
Basically 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. -
First, try logging out, then relogging. Then, see that you update your Eddie to the latest version, which is currently 2.26.2.
-
Hello , I can't connect to any server; the list is empty and the button is greyed out. Could someone please help me?
-
No available server when using vpn
Tech Jedi Alex replied to bobo06's topic in General & Suggestions
First post. I locked the previous thread, so let's continue here. Please close Eddie, reopen, then try a connection once, then provide a system report.Your log is unfortunately difficult to read; somehow there are no newlines in it. Please do not copy-paste the logs or the system report, but save it in a file, and upload that file, as per the instructions in the linked thread. Thank you! -
You mean airvpn.org. But no, it isn't. It's a dead giveaway if one of the language options for the website is Simplified Chinese. Chinese wouldn't be the first or second language choice for an European/Italian company. Though, you explicitly wrote that you know it's not affiliated with AirVPN, so I guess you knew deep within they're not part of AirVPN, anyway The only two websites affiliated with AirVPN are eddie.website and ipleak.net.
-
Dear 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.txt
-
-
Swiss Servers always disconnects and packet loss?
Staff replied to Gandalf15's topic in Troubleshooting and Problems
Hello! The problem with IPv6 has been almost resolved through a switch replacement. However, a moderate packet loss on ICMPv6 traffic persist, up to 2.5% as far as we can see. Datacenter technicians are still investigating but according to our tests all the Swiss servers are perfectly usable with IPv6 too, currently: TCPv6 records negligible packet loss / re-transmission < 0.5% Kind regards -
Hello! @MasieX We mean Developer options in your phone’s Android settings. On Samsung Galaxy devices, open Settings → About phone → Software information, tap Build number seven times and enter your PIN if prompted. Samsung’s instructions: https://www.samsung.com/uk/support/mobile-devices/how-do-i-turn-on-the-developer-options-menu-on-my-samsung-galaxy-device/ Then open Settings > Developer options > Select mock location app and select Eddie. @UncleAdolf Could you please check that Eddie is selected under “Select mock location app”? Enabling Developer options alone does not complete this step. Android documents this setting here: https://developer.android.com/studio/debug/dev-options#debugging If Eddie is already selected and the error persists, please provide your phone model, Android version, Eddie version and the exact error message, so we can investigate further. Kind regards
