Staff

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