Not connected, Your IP: 216.73.216.52
Online: 46666 users - 574037 Mbit/s total BWAll Activity
This stream auto-updates
- Past hour
-
-
-
- Today
-
-
-
-
-
-
-
- Yesterday
-
Fedora network nftables netlock problems,
ylixia replied to Stolen Compass's topic in Eddie - AirVPN Client
Exact same error on Ludora 44, using either Eddie 2.26.2 or 2.27.2 (experimental). Reverting to 2.24.6 is the only fix I've found. -
.thumb.png.8be84fd39f94c1640ac8c5456fbf3449.png)
All LA servers keep having issues
Staff replied to haruka_ff's topic in Troubleshooting and Problems
Hello! Thank you for the additional details and for correcting the incident time to October 5 at 07:58 UTC. We found a matching IPv4 reachability alarm for Revati, so our investigation includes IPv4 as well as IPv6. Our capacity measurements rule out sustained server overload from “too many users” during the period reviewed. We checked all five Los Angeles servers over September 29 - October 6: Peak sampled total CPU utilization remained below 36% on every server. Memory utilization remained below 5.6%. Connection-tracking table occupancy remained below 61% of capacity. The highest traffic rate measured over approximately five-minute intervals was 6.1 Gbit/s in both directions (6.1 + 6.1 = 12.2), on 10 Gbit/s full-duplex interfaces. At the reported time, Revati's total CPU utilization was approximately 20–24%, and its connection-tracking table was about 30% full. These measurements show substantial capacity headroom. They do not, however, exclude very brief network events or issues affecting individual paths or queues. We are investigating the recurring connectivity interruptions internally and are evaluating involving the provider to help establish their cause. The cause has not yet been confirmed. As previously explained, a partial failure percentage across our monitoring probes can coincide with a complete interruption on a particular customer's path. We appreciate the reports you have provided. Kind regards -
-
-
Hello, 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.
-
All LA servers keep having issues
pHxaq replied to haruka_ff's topic in Troubleshooting and Problems
I posted about Flegetonte - AirVPN when the server was announced, it shows a huge list of issues every single day. Clearly, from my experience using this and a few others, there's something broken in some servers. - Last week
-
All LA 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.) -
All LA servers keep having issues
haruka_ff replied to haruka_ff's topic in Troubleshooting and Problems
Hi, I used wireguard on port 1637. The connection stayed connected as wireguard doesn't have the concept of "disconnection" on packet loss; what I saw was that there are outgoing packets, but 0 incoming packets. I also checked the logs, and you are right, it did happen around 07:58 UTC as around that time I tried to switch to another server. Unfortunately, as there is no "disconnection" due to packet loss, I don't have other logs about it. (I use wiresock as I need per-application split tunnel.) -
All LA 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 LA 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 LA 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.
-
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. -
ANSWERED What's going on with Alruba?
Staff replied to 1234asdfghjkl's topic in Troubleshooting and Problems
@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! -
ANSWERED What's going on with Alruba?
Staff replied to 1234asdfghjkl's topic in Troubleshooting and Problems
@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?
