Jump to content
Not connected, Your IP: 216.73.216.49

All Activity

This stream auto-updates     

  1. Past hour
  2. Today
  3. @rpoyner Hello and welcome aboard! We see the problem. First, please make sure you have downloaded Eddie notarized version exclusively from AirVPN web site. Then, you need to avoid app translocation by moving Eddie to the /Applications folder using the Finder app. Once the translocation doesn't take place anymore, please follow this message if any problem persists: https://airvpn.org/forums/topic/70745-eddie-cant-connect-to-any-server/?do=findComment&comment=249545 Kind regards
  4. Hi, since 2026-02-01 my Debian Trixie system can’t update the Eddie APT repo. Debian repos are fine, only eddie.website fails. Error: http://eddie.website/repository/apt stable InRelease sqv: Policy rejected signature because SHA1 is not considered secure since 2026-02-01T00:00:00Z Key: C181AC89FA667E317F423998513EFC94400D7698 Is there an updated repo signing key / re-signed InRelease available (SHA256+), or a recommended fix/workaround until it’s updated? Thanks!
  5. Cant get airvpn to connect. Attaching the error code line, something to do with wireguard, Im not too savvy at this, any help would be appreciated. E 2026.02.01 08:42:18 - WireGuard > Error: Executable '/private/var/folders/2y/7rnngmrd6fv08b226ryfpksh0000gn/T/AppTranslocation/9BF1287F-A4DC-45F3-8804-E4F4675DFC2B/d/Eddie.app/Contents/MacOS/wireguard-go' not allowed: Not owned by root;
  6. Hello! No need for MSS clamping when using WireGuard, just modify the MTU if necessary. Since MSS clamping 1. becomes necessary only when you can't modify MTU, 2. needs packet mangling (WireGuard does not expose any option for it) and 3. requires anyway a server side modification, just operate through MTU. In OpenVPN (only when working over UDP), where networking management is a bit different, you can seriously consider the mssfix directive if you have any "fragmentation" problem that causes packet loss and poor performance. mssfix announces to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes. See also OpenVPN manual: https://openvpn.net/community-docs/community-articles/openvpn-2-6-manual.html In Eddie you can add custom directives for OpenVPN in "Preferences" > "OVPN Directives" window. Kind regards
  7. Yesterday
  8. Related to this, when selecting Wireguard in Eddie, is the MSS set to 1320 by default? If not is it recommended to add it to OVPN directives?
  9. Its a shame. These were among the absolute fastest (especially Chumukay) when they came on board. They smoked the high powered Chicago servers but they are not reliable for the past week or two. Right across the border in Chicago apparently nobody is attacking those servers.
  10. I doubt that the processor is the reason however I am using a Ryzen 9 3rd gen on an amd motherboard. Simply putting this here because I notice you guys are running i5 or i7 chips.
  11. Hello! Yes, current DDoS / flood unfortunately. Kind regards
  12. Hello! Yes. Server side it is 1420 bytes, so this is your upper limit too. Thus you can test up to 1420 bytes to find the MTU that can provide you with the best performance. Kind regards
  13. Do you know why these new servers are having high packet loss?
  14. But if I select a bigger MTU than what you have server-side, won't the effective MTU of the applications running in the tunnel still be constrained to the server MTU?
  15. Hello! It's a compromise to avoid fragmentation on most networks, except PPPoE ones, where smaller 1280 bytes MTU is required. https://blog.silvio.cloud/2_WireGuard_and_MTU_MSS You may test different MTU to find the optimal value for your network (the one that can provide you with the best performance). Kind regards
  16. Last week
  17. Why is the MTU on files generated from AirVPN's config generator just 1320 instead of the normal 1420 for Wireguard? Not saying that this is a bad thing, but just curious.
  18. AirVPN should support DNS over TLS within the VPN tunnels, but currently, this is not the case. Of course, we know that DNS over TLS does not provide any benefit because all DNS traffic goes over the VPN as well (which is also stated in the service description). However, I use Linux, and when the VPN is off, I always keep DoT on. The setting is simply enabled by DNSOverTLS=yes at the resolved.conf file. Because 99% of the time I do not use VPN, I prefer to keep the DoT setting on and not disable it whenever I start a VPN session. But when deploying a VPN session from a WireGuard conf file, the DNS resolution is halted. It is possible to reach the internet through direct IP-address-based connections, but DNS resolution does not work at all. I see that the internal DNS server (10.128.0.1) does respond to the incoming requests at port 853, and I receive the responses, but that is all. Naturally, it is not possible to sniff more deeply into the content of the DNS packets with Wireshark because they are encrypted. But there is a lot of that traffic going back and forth through the tunnel. Do you have any idea what might be wrong? If the DoT setting is disabled, the DNS resolution works inside the tunnel as it should.
  19. Eddie 2.24.6, very laggy GUI in that its slow to draw the interface, checked mono, there is no updates for it. Eddie works when its connected but the interface is slow. ( think late 90s internet and Jpg downloading effect line by line but a little faster ) Eddie 2.21.8 didn’t have this bug, it was responsive except the server list often jumped around, however when Eddie's interface was open it did stop Kubuntu panel menu from opening. Tried 2.24.6 on mint 23.3 cinnamon on a similar laptop and the bugs here as well. Thankfully I am not the only one to experience this. Eddie 2.24.6 system report is interesting, its slow at first, garbled text, CPU maxes out then eventually the report if compiled but scrolling through it causes the text to break up. Laptops specs : Kubuntu Operating System: Kubuntu 24.04 KDE Plasma Version: 5.27.12 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.13 Kernel Version: 6.8.0-90-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-10210U CPU @ 1.60GHz Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics
  20. I'm not sure that age verification handling is in the best interest of the service as a whole.
  21. @earthlight Hello! Possible explanation: the listening service does not listen to the VPN interface or is not running. More in details: when the firewall is on, the test packet is silently dropped, so the port tester does not receive a reply and throws error 110 (timeout). When the firewall is off, the attempted connection by the port tester does not time out anymore because the packet is not silently dropped, but the relative connection is reset via TCP RST because the final VPN interface port does not exist and the device kernel is configured to reset connection to non-existing ports. This is consistent with the previous description and explanation. If UPnP works fine when the VPN is off, then it is active on the listening software too. Due to how UPnP works, the listening software will bind to the physical network interface and not to the VPN interface, causing the problem. Please note that if Network Lock is not active you will also suffer traffic leaks outside the VPN tunnel because of UPnP. Please keep UPnP disabled at least on the settings of the listening software. Consider to disable it at router level too as a pre-emptive safety measure if it is not strictly necessary. A checklist you can consider to follow: https://airvpn.org/forums/topic/66388-port-forwarding/?do=findComment&comment=243305 Kind regards
  22. I would be really keen to hear AirVPN's position on this too. It seems to me that the UK would be unable to enforce any fines on a non-UK company for not complying with age verification. Presumably they'd be able to force UK ISPs to block VPN companies websites, but beyond that I don't see what else is in their power to do.
  23. port forwarding has been working completely fine since I started using airvpn and yesterday it suddenly stopped working while I was trying to connect a friend to my game server in Hytale (it worked fine with this game before I don't believe it's the cause). canyouseemee says iIcan't be found. I have not been able to fix it. I've looked at countless forum posts and no one seems to have had my exact issue. Went to bed and thought maybe it'll fix itself, nope. I usually like to fix these things myself but after turning my firewall off, checking if any permissions changed, checking my airvpn settings, making a NEW port, resetting my router as well as turning it off and on a bunch, I don't know what else to try Like I mentioned in the title the error changed to 111 when I turned my firewall off. Edit: I forgot to mention UPnP is actually turned on on my Router and working fine when I turn my VPN off. Any help would be appreciated thank you!
  24. Hi there, it seems in the UK it is looking more and more likely that VPN's will need to be age verified to be used. Information on this can be found here. Does AirVPN plan on following this guidance and adding age verification? Also, has there been any consideration towards this by the AirVPN team? I am aware the bill has not yet fully made it through government, but I am curious at what actions AirVPN will take to either comply or not-comply with the possible demands. I am not all that worried about this, just really curious on what other people's takes are, and if AirVPN has any plans towards this. Thanks for reading
  25. Thanks for the quick and helpful answer! After some more testing, it seems everything is actually working fine, other users can reach me and browse my shares, I just can't reach myself. Hopefully this can help others in the same situation in the future
  26. Tomorrow I will test on a fresh Archlinux install if I can reproduce the problem. But I am using a symlink, for sure.
  27. @p1pb0y Hello! We can reach your software from the Internet on the IP address you're currently connected to, port 60798, i.e. your slskd receives the packet and replies accordingly. So your port forwarding configuration, firewall configuration and slskd bind/port setting are all fine and working properly. The logged error must have a cause unrelated to AirVPN port forwarding and also unrelated to the container's firewall. Kind regards
  28. Hello good people, hope can you help me think why I'm not getting port forwarding to work on the slskd soulseek client (https://github.com/slskd/slskd/) I am running it in docker alongside gluetun. I am using the same setup for a working port forwarding with qbt, so I know it is possible FWIW I am using wireguard. I have: Configured forwarded port 60798 in airvpn dashboard (also forwarded 60799, as some clients needs this, but probably not slskd) Set up the correct listering port in slskd application Opened the gluetun firewall (FIREWALL_VPN_INPUT_PORTS) for 60798 and 607999 Verified that the port 60798 is open using "test open" - TCP on ipv4 is open on 82.102.27.195 (Camelopardalis) Alas: The slskd logs says it is failing to communicate with my user on 82.102.27.195:60798. I have checked the other posts on the forum, and slskd does not have a NAT/PMP option to toggle. Is there anything else I am not thinking about? Or does this narrow it down to slskd? Thanks!
  1. Load more activity
×
×
  • Create New...