Jump to content
Not connected, Your IP: 216.73.216.2
AirVPN

All Activity

This stream auto-updates     

  1. Past hour
  2. ELBNCID ELBNCID joined the community ...
  3. ahaowe456 ahaowe456 joined the community ...
  4. Some Guy Some Guy joined the community ...
  5. Nora Burgstaller Nora Burgstaller joined the community ...
  6. ThorgarIV ThorgarIV joined the community ...
  7. esengwafu esengwafu joined the community ...
  8. Pimauchama Pimauchama joined the community ...
  9. Today
  10. wert234243 wert234243 joined the community ...
  11. spuniondread spuniondread joined the community ...
  12. pungone pungone joined the community ...
  13. reversevpn started following Port Forwarding woes ...
  14. reversevpn
    Did you configure UFW or iptables to allow the port through?
  15. Yesterday
  16. REDAKTORN REDAKTORN changed their profile photo ...
  17.    user287634 reacted to a post in a topic: Six new 10 Gbit/s servers available (UK) ...
  18.    TallDude reacted to a post in a topic: Black Friday 2018 Week ...
  19. shokamber shokamber changed their profile photo ...
  20. moving shadow
    Greetings! I cannot get the port forwarding to work for reasons unknown. This photo shows what I have listed in the client forwarding area. Both scratched out ports are the same number. And here in SoulSeek (Well, nicotine+ client) I have the matching port number, with no typos, specified in the settings to match up with what was allocated to me from AirVPN. Port check fails miserably, and I've tried other apps like torrents instead with the same result -- port is closed. Not sure what else there is to do or what I'm doing wrong, any guidance would be great. OS is an Arch Linux variant for aarch64 devices, running KDE desktop Thanks kindly!
  21. Staff
    Hello! We can't reproduce the problem on London servers, entry-IP address 1 and 3, port 1637. Since you have PPPoE please force WireGuard interface MTU to 1280 bytes and test again: the problem seems consistent with a too large MTU. Note that currently about 1200 active and working connection slots are operational and working through WireGuard on UK servers (most of them to port 1637, entry-IP address 3). Is anybody else experiencing this specific problem? Kind regards
  22. Clodo started following Eddie Desktop Edition 2.25 beta released ...
  23. Clodo
    Fixed, thanks for the report.
  24. reversevpn
    What is your response to the requiring of OS-Level Age Verification in California? For companies like AirVPN, what does it even mean to indicate an age during OS Setup? Are you planning to withdraw your servers from there?
  25. reversevpn started following Anyone using Bitcoin full node over Air server? ...
  26. reversevpn
    I've got a Monero full node + P2Pool over AirVPN server. BTC seems too difficult to mine and doesn't have the same privacy protections.
  27. Last week
  28. torup302
    Hi, just adding another data point here. I’m experiencing very similar behaviour to what the OP describes, starting within the last 24–48 hours. WireGuard tunnel comes up normally Handshake appears to succeed transfer: X B sent, 0 B received No DNS, ICMP, or TCP traffic ever returns through the tunnel This is consistent across multiple AirVPN WireGuard endpoints (UK/London and others) and ports (including 1637). Environment: Headless Linux server WireGuard via Gluetun / wg-quick IPv4 only Same network where OpenVPN (TCP 443) connects and passes traffic immediately I’ve tried to eliminate local causes as thoroughly as possible: Multiple AirVPN servers and ports -> same result Local firewall disabled -> no change MTU adjustments ->no change Hard-coded endpoint IPs -> no change Explicit DNS (1.1.1.1) -> no change OpenVPN TCP works immediately on the same host and network I captured traffic on both LAN/VLAN and WAN (PPPoE) interfaces: Outbound UDP packets do leave my network Source IP is correctly NAT’d to my public IP Packets are sent to the AirVPN WireGuard endpoint No inbound UDP replies are ever observed on WAN This suggests the packets are leaving correctly but no return traffic is making it back, ruling out local NAT/firewall issues on my side. What stood out to me in this thread is the report that Eddie only works once “Check DNS” is disabled. While I understand WireGuard itself is not DNS-dependent, the overall failure mode (handshake established but no usable traffic) matches my setup almost exactly. At this point the behavior feels consistent with either: a WireGuard backend routing issue, or something affecting the return path for WireGuard traffic on certain networks Happy to provide redacted packet captures or server names if that would help narrow it down.
  29.    Squirrel_Mum reacted to a post in a topic: Newbie to VPN with some Eddie/qbittorrent questions ...
  30. Tech Jedi Alex started following Eddie Desktop Edition 2.25 beta released ...
  31. Tech Jedi Alex
    Can reproduce. You may build eddie-ui-git from AUR instead, this one works.
  32.    Tech Jedi Alex reacted to a post in a topic: What was the last sale price at Christmas 2025? ...
  33. Tech Jedi Alex
    You may find this useful, then..
  34.    Erquint reacted to a post in a topic: Eddie Android edition 4.0.0 preview available ...
  35. Staff
    @Erquint Hello! Thank you for your tests! Beta 2 has multiple problems and it turned out to be too unstable on various Android versions. Please hold on, beta 3 is addressing the problems you experienced and coming out soon. Kind regards
  36. Esurient
    Still working on it, probably release it when it's good enough
  37. harold.lewis
    Not able to download the experimental version of Linux Eddie VPN Client for Arch: is returning 'Error Code: 500 Internal Server Error'
  38. Erquint
    Ouch, it seems I jumped the gun with my impression of Beta 2. It worked well the first time I launched it after updating. But now it seems very broken. Tells me I can't pick a server without logging in, despite me having done that in a previous launch to cache the internal bootstrap configs, fails to log in without manual tunnelling first, and the worst part is that it freezes and crashes all the time now while logged in. This is way unstable compared to Beta 1. Maybe a clean reinstall can remedy this, but I'm sticking to never logging in for the time being until I get to testing that.
  39. mefflecakes
    Just re-enabled ipv6 on my router, PC and Eddie but still no luck 😕 I've got nothing set on the router that should block traffic. Very strange.
  40. Staff
    Hello! Holy moly... If you have disabled IPv6 on your system but you kept IPv6 layer on Eddie then the IPv6 DNS and route check correctly fail. Kind regards
  41. mefflecakes
    Well I've disabled IPv6, might that do it? :D
  42. Staff
    Hello! On the contrary. This means that Eddie could not resolve names on the specific DNS set on the system after the connection was established. If the handshake failed there was no communication between your system WireGuard and the VPN server. If the DNS check is disabled and the connection works, then the handshake is successful and the previous DNS check failure was a false positive. On your Arch Linux machine: the handshake is successful. DNS check fails on IPv6 while it is successful over IPv4. However, on Alphecca IPv6 and DNS6 work fine (just tested). Alkaid was decommissioned in 2019, so it must not appear on Eddie and you should discard Alkaid-specific profiles. Maybe you meant a different server? Try to disable Eddie's DNS check just in case it's a false positive or it is related to IPv6 problems in your machine. On your macOS machine: the handshake fails, so DNS is not (and can not) be checked. WireGuard does not communicate with the servers at all. Any anti-malware tool that might block communications? Kind regards
  43. mefflecakes
    Hello, Thank you for the quick response. To clarify, I am experiencing this specifically on the Netherlands cluster (specifically Alphecca and Alkaid), but the behavior persists across several other EU nodes. Per your request, I have attached the Eddie System Report from my macOS machine captured immediately after a failed DNS check. As requested, I confirmed that if I disable "Check DNS" in Eddie, the connection establishes and data flows normally. However, my primary concern remains my headless Arch Linux server using native wg-quick. On this machine: I am using a generated WireGuard configuration with hardcoded IP endpoints to bypass any potential airdns.org resolution issues. The handshake consistently fails (0 B received) despite the server being reachable via ICMP ping. I have verified that systemd-resolved is active, and I am manually specifying DNS = 1.1.1.1 in the interface config to ensure I am not relying on internal VPN DNS for the handshake/initialization. If the DNS is strictly local, it is unclear why the Eddie "Check DNS" toggle acts as a "kill-switch" for the entire tunnel establishment on the same network where a native WireGuard handshake is failing. Attached are the Eddie reports you requested, I'm happy to focus on just ensuring we get Eddie connecting, because if this is an issue relating to my network configuration in some way then everything else should fall in place. Arch Linux - Eddie_20260301_170720.txt ArchLinux Sysreport.txt MacBook Pro SysReport macOS - Eddie_20260301_170301.txt
  44. Erquint
    Beta 1 worked well for me using configs. Especially given that new configs could be generated right in the app once you manage to bootstrap. Very much appreciate the intelligent care that went into engineering of the app. That is the reason I'm so late to try the updated version. One issue was bugging me, however, and I probably mentioned it before, but the QS tile was not functional in my region due to aforementioned issues. Beta 2 does seem to successfully cache and reuse the internal server configs, without needing to export them, once you manage to bootstrap it once. Well done. This inherently also fixes the QS tile issue. For future updates, I would like to ask for an option to spoof the app icon, QS tile and persistent notification for such regions where random searching of citizens' personal devices by cops in public is mandated and VPN usage becomes increasingly more criminalized. Masquerading as some consumerist drivel, maybe an AliExpress knock-off screaming ✨ 17% off sale! ✨ in flashy corpo palette without trademark violation, would defuse any suspicion.
  45. Staff
    Hello! That's a totally separate issue which involved authoritative nameservers of airvpn.org more than two days ago and was completely resolved in a very short time, as the users writing in that thread correctly reported. Moreover it did not have any impact on VPN infrastructure. We can't reproduce this issue and by examining tickets on the last 24 hours there's not even one complaint about it. Can you list the specific servers you experience this problem on? Please note that DNS is set locally by WireGuard related script according to the DNS address(es) included in the profile (wg-quick on Linux tries to call resolvconf). DNS is not pushed by the VPN server, because WireGuard does not have any DHCP function. However, WireGuard handshake is not related to DNS, keep in mind. Kind regards
  46. mefflecakes started following Headless Linux - unable to connect via wireguard ...
  47. mefflecakes
    I’m wondering if others are experiencing persistent WireGuard handshake issues over the last 24–48 hours. I am seeing symptoms very similar to those described in this recent thread: https://www.reddit.com/r/AirVPN/s/FsrrAQglfa (packet loss and "authoritative nameserver" errors). I am running a headless Arch Linux server using wg-quick. Despite using a variety of ports (including 53 and 443) and hardcoded IP endpoints, I am stuck at: transfer: 0 B received, [X] B sent Interestingly, I was able to get a connection established on a separate pc using the Eddie client, but only after going into Preferences and unchecking 'check dns'. When that box is checked, Eddie hangs on checking dns. Once unchecked, data flows perfectly in both directions on the pc. However, this "fix" isn't directly applicable to my primary headless setup, where I'm using native WireGuard tools and manual policy routing. My setup: • OS: Arch Linux (Headless) • Protocol: WireGuard (via wg-quick) • Handshake Status: 0 B received (Sent packets are never acknowledged). • DNS: I have tried bypassing internal DNS by setting 1.1.1.1 in the config, but the handshake still refuses to complete on the Linux side. • ISP/Network: Same network where Eddie (with "Check DNS" off) works. Is there currently an issue with the backend DNS validation or the internal API that WireGuard handshakes rely on? It seems that if the "DNS check" fails, the handshake or the routing associated with the tunnel is being stalled. I'd like to know if this is a widespread issue and if so, is it being worked on?
  48.    Erquint reacted to a post in a topic: Eddie Android edition 4.0.0 preview available ...
  49. Staff
    Hello! OK, if you see Eddie simpler then go for it, we're glad to know that it meets your needs. In the way you're running Eddie, it will already select the server with the best rating. The round trip time with your node among the ones it considers has a significant weight to pick the server. If you want to narrow down Eddie measurements to make the choice more appropriate for your needs you can consider to define a white list of your favorite servers or pick a specific country to connect to. In that case, Eddie will pick the best scoring server included in the white list, or the best scoring server in the specific country. If you want to determine unconditionally the server with the lowest round trip time, you can use specific tools and then tell Eddie to connect to the specific server you find with the best round trip time. Consider these sh commands by @OinkOink: https://airvpn.org/forums/topic/47335-solved-find-the-best-server-lowest-ping/?do=findComment&comment=259294 Kind regards
  50.    AIGLON reacted to a post in a topic: Eddie Desktop Edition 2.25 beta released ...
  51. zedik
    I figured out Eddie-cli. Its 3 initial commands:↓ 1. ↓ eddie-cli --protocol=WireGuard --port=1637 --save 2. ↓ eddie-cli --servers.scoretype=Latency --save 3. ↓ eddie-cli --network.lock=true --save After that to start Eddie: ↓ eddie-cli --connect So far so good — I can watch movies with Eddie-cli on. AirVPN Suite will most likely be better but to me is to complicated. I wish someone on forum will come with simple, for dummies AirVPN Suite how to with automatic lowest latency, please.
  52. moving shadow moving shadow changed their profile photo ...
  53. moving shadow
    I didn't bother waiting. Service seems worth it, I got a trial account and lived up to my expectations. Thank you
  54. JamesBond00 started following Three new 10 Gbit/s servers available (CA) ...
  55. JamesBond00
    These were very much needed so I'm glad to see them added to the list
  1. Load more activity
×
×
  • Create New...