Staff

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

Hello! As noted the claimed vulnerability and PoC was/were not filed through the proper channels. According to the report we could finally access, the vulnerability affects macOS (not Windows or Linux), only in case the user checks "Preferences->UI->CLI" in order to have "eddie-cli <options>" available in a command line interface. macOS is the only system for which the stand alone Eddie CLI version is not offered. While the report is being investigated please do not enable that option and run Hummingbird if you need a CLI based program to connect. We will update this thread and of course, should the problem be confirmed, the devs will release a new version. Kind regards