Staff

Hello! Thanks, we are aware of the problem. Unfortunately the registrar does not allow to change this setting on the authoritative DNS. For a deliberate choice, airvpn.org is one of the very few domain names we operate for which we do not manage directly the metal behind our own authoritative servers. We will anyway remind the provider of the problem as we did in the past and we will consider whether it's appropriate moving the domain name for this problem. Kind regards

@Peter Laanstra Hello! There isn't (and there never was) any throttling policy at all on any AirVPN server. Please test directly from the host (no containers) to quickly discern whether the problem is GlueTun specific or not. Please test different torrent software as well as smaller WireGuard interface MTU (start testing from 1280 bytes). On GlueTun, FIREWALL_VPN_INPUT_PORTS environment variable must be set properly. The fact that you unset it sounds like an error: why do you say that you don't set it to avoid firewall conflicts? This environment variable is read by the container exactly for firewall rules. If the variable is empty, no unsolicited incoming packets will be allowed on tun0 (or any other VPN interface). Please feel free to elaborate. Kind regards

@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

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

Hello! Yes, current DDoS / flood unfortunately. Kind regards

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

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

@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

@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

@stallard Hello! At least one error is visible: remote port number differs from local port number. Due to how a torrent program works you must configure matching remote and local ports (for additional details please read the FAQ). Just delete the "local" field of your remote port in your AirVPN account port panel, adjust qBittorrent listening port accordingly, re-start both VPN connection and qBittorrent and follow this checklist: https://airvpn.org/forums/topic/66388-port-forwarding/?tab=comments#comment-243305 Additional tips for the errors you get: Error 111 (connection refused): the connection has been actively reset by the destination system (the client, in this case your system) through a TCP RST Error 110: no reply from the destination system (client), the sent packet has been silently dropped Further information on p2p programs: https://airvpn.org/faq/p2p/ Kind regards

Hello! Your /etc/resolv.conf file is not a symlink according to Eddie. Question: in NetworkManager configuration, do you have something like: [main] dns=systemd-resolved If you set DNS directly via NetworkManager and NM is not configured as above, NM overwrites /etc/resolv.conf file (this would explain why it's not a symlink when you run Eddie). At the next systemd-resolved (re)start, it is over-written again as a symlink (this would explain why you see it as a symlink in your initial report and you need to re-start systemd-resolved each time). You should manage DNS either through NetworkManager only, systemd-resolved only (explicit delegation to systemd-resolved must be enforced on NM if you need to run it for other reasons), or by getting rid of Windows-like DNS management (go back to /etc/resolv.conf rock solid, old school management, optionally having NM manage resolv.conf directly). (*) Avoid any hodgepodge of different DNS managements, they come from Windows-style duct-taped DNS management jumble that have caused decades of huge problems including DNS leaks (we remember well svchost.exe DNS leaks disasters). (*) Should you decide to disable systemd-resolved completely remember to stop, disable and mask it, otherwise it may (will) be re-enabled and re-started without your knowledge by systemd. Maybe not, see here: Note how Eddie restores the previous DNS on enp12s0 correctly, and the previous resolv.conf backed up file that was not a symlink but contained the VPN DNS possibly for the reason previously explained or maybe for a mixture of NM / systemd-resolved concurrent usage. Try to delete the resolv.conf backup file and follow the previous suggestions, in particular make sure your system relies on a clean DNS management, then feel free to let us know whether the problem gets resolved. That's fine and expected, it's a safety feature of Eddie. If you want to prevent Eddie from managing DNS you have to disable this check by unticking "Check Air VPN DNS" in "Preferences" > "DNS" window. Kind regards

Hello! The IPv6 networks are up and all the servers are operating normally. Kind regards

Hello! Yes, all the IPv6 networks of all the servers in Alblasserdam are 100% down, therefore the system detects high packet loss. IPv4 infrastructure is fine at the moment. We have contacted the datacenter and we are waiting for a check and if possible an expedite solution. If this is not feasible, we will determine whether to reopen the Alblasserdam servers exclusively with IPv4 or not. Amsterdam infrastructure is not affected, different datacenter and different providers. Kind regards

@zebulon Hello! Please note that Network Lock has nothing to do with DNS settings. Now, the problem seems here: In other words, the previous DNS setting for wlan0 were 10.128.0.1 and fd7d:76ee:e68f:a993::1 according to Eddie. So it's possible that Eddie restores the system DNS settings as expected, but with the same VPN DNS, even for /etc/resolv.conf. Somehow in a previous session the proper DNS settings were not restored and Eddie takes (now correctly, the error must have occurred in a previous session) those settings as the original system settings in subsequent sessions. Please try this: set all the correct DNS (globally and for each interface) while Eddie is not running, delete Eddie configuration file ~/.config/eddie/default.profile, make sure that only WiFi or only Ethernet is connected, re-start Eddie and try again. Kind regards

Hello! You can modify this behavior in Eddie's "Preferences" > "DNS" window. Kind regards

Hello! Thank you very much for your tests. If you don't want to rely on a free VPN, you may also use a configuration file generated by our Configuration Generator, needed only for the first time. You'll need access to one of the AirVPN websites. If you cannot reach the main website, feel free to open a ticket to receive mirror addresses. Kind regards

thank you for going the extra mile, albeit it does not work like a charm on LineageOS 23. Tested different values with Wireguard and AmneziaWG - with or without CPS. It leaks my IP via WebRTC. Hello! Thank you very much for your tests! WebRTC is managed by the browser. It is aimed at connecting directly to remote peers through STUN, NAT traversing or other methods all involving the ability to bypass the VPN tunnel (provided that the routing table has preserved the original default gateway). On desktop systems any leak can be prevented by firewall rules (Network Lock) while on Android (where we do not have privileges to manage a firewall) you should enable both "Always on VPN" and "Block traffic if VPN is inactive" for Eddie. These options must prevent any possible leak. Disabling WebRTC on the browser, if you don't need it, is also a more specific solution and an additional layer of defense. Lineage OS 23 is built over Android 16. The latest Android versions only allow notifications to be enabled at the express choice of the user and not the app. Eddie should have shown this message: Please note, in case the current Android security policy does not allow this setting to be changed from within this app, you explicitly need to change it from the Android system settings panel. Also please note, in case notifications are not enabled, Eddie will not work properly. Kind regards

Hello! We think that the problem is on your side. Castula is absolutely perfect just like other servers you experience this problem on. We have no complaints whatsoever about any of the servers you mention. Note that Castula, Chamukuy, and Elgafar are all connected to the same upstream in the same small subnet. Your tests have been instrumental to make us aware of the problem (SYN flood and similar events) frequently occurring on specific Canadian servers, so thank you! A good thing you can do on your side is black listing the servers that don't work well for you. You have anyway a vast range to pick from. Keep us informed if the problem suddenly appears on one or more of the servers that are perfectly fine for you now. Kind regards

@Baraka Hello! As you already know from the ticket, we could reproduce the problem only on Tyl with 5% packet loss from any source. We determined It was a momentary problem due to SYN flood. After all, the server was decently resilient to the attack showing only a limited packet loss during the flood. At the moment we see packet loss < 1% from 20 different countries and dozens of datacenters in the world toward any server including Tejat (0.0%), so we must consider the problem not reproducible at the moment. Since 3 additional 10 Gbit/s servers were added recently in the very same datacenter where Kornephoros lives, you should test them as well: https://airvpn.org/forums/topic/78643-three-new-10-gbits-servers-available-ca/ They offer you additional options on top of the several Canadian and USA servers which you already connect to without packet loss. Kind regards

Hello! Yes, by doing it in one command line through cuckoo, one of the programs of the AirVPN Suite. The Suite must be installed first and configured to enable traffic splitting. A thorough user's manual is available here: https://gitlab.com/AirVPN/AirVPN-Suite/-/blob/master/README.md AirVPN Suite dedicated page: https://airvpn.org/linux/suite/ Quick reference for the necessary steps (required time: 2-3 minutes if you've read the manual): Install the AirVPN Suite on your system Configure Bluetit to support traffic splitting by entering, in /etc/airvpn/bluetit.rc, the line allowtrafficsplitting on Re-start Bluetit, make sure that Plex is not running, and connect to your favorite VPN server Switch to user airvpn with command airsu - this command is not always mandatory but it may be necessary to prepare the environment (variables etc.) especially if you run a DE with Wayland Run Plex and/or any other application whose traffic must flow outside the VPN tunnel with command cuckoo --run /path/to/application_name from user AirVPN Kind regards

@constant_headache Hello! The message means that either: The device linked to that port is not connected to any VPN server. If the port is linked to "All devices" then the message implies that no device at all is connected to any VPN server. Or you have disabled the port from your AirVPN account port panel Kind regards

Hello! Yes, and did you turn memory integrity off? If so, and the problem persists, try this from a command prompt with administrator privileges (find the correct path with hash from the WireGuard failed installation log): pnputil /add-driver "C:\Windows\Temp\<hash>\wireguard.inf" /install Then send us the whole output. Kind regards

@Baraka Thank you. After the private dialogue in the ticket you kindly opened with the support team we could manage to reduce the packet loss of Tyl and Tejat to 1% from/to the mentioned servers to/from the dozens of datacenter we operate servers in. Packet loss ≤ 1% is ideal for any application and purpose. Can you confirm that the problem is solved in Tyl and Tejat? We will proceed in the near future to investigate again about Mintaka, Lacerta and Cephei, where we could not reproduce the problem during our initial tests (we detected packet loss ≈ 0.0%). Kind regards

Hello! Please make sure that the FIREWALL_VPN_INPUT_PORTS environment variable is properly set. Note that FIREWALL_VPN_INPUT_PORTS and FIREWALL_INPUT_PORTS are different variables for ports of different interfaces. See here: https://github.com/qdm12/gluetun-wiki/blob/main/setup/options/firewall.md Kind regards

Hello! Totally correct. Please check here for power and limitations of AirVPN's remote inbound port forwarding system: https://airvpn.org/faq/port_forwarding Please see here for p2p targeted optimization: https://airvpn.org/faq/p2p/ Kind regards