Staff

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! 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

Hello! Please upgrade first to Eddie 2.24.6. https://airvpn.org/windows Kind regards

@zeroone1zero Hello! The critical error: therefore the problem is not Eddie related. The system can't find "wireguard.inf" file. It could have been deleted by an antivirus or its access is prevented by Defender's Controlled Folder Access. Please disable any antivirus and also in Windows Defender disable momentarily CFA (Windows security > Ransom protection > Controlled Folder Access) and try again to install. Please make sure you grant the installer administrator privileges. If the problem persists, try also this: Open Windows Security Go to Device security Open Core isolation Turn Memory integrity OFF Reboot the PC and try again to install with administrator privileges If the installation is successful, remember to re-activate the protections you disabled. Kind regards

Hello! Eddie Android edition 4.0.0 beta 2 is now available featuring improved AmneziaWG support and strengthened logic against AirVPN bootstrap server blocks: https://airvpn.org/forums/topic/77633-eddie-android-edition-400-preview-available/ Kind regards

Hello! That's self evident by port definition (a logical construct that identifies a process). If a software is "not listening to" a port then the port does not even exist on your side - if we had to explain things like that, then we could end up explaining what a pointer and a cursor are and how to use a mouse and a keyboard, just saying , but in this case everything is in the FAQ section, please spend a few minutes to read the documentation. https://airvpn.org/faq/port_forwarding A checklist for the readers or future needs: https://airvpn.org/forums/topic/66388-port-forwarding/?do=findComment&comment=243305 Kind regards Holy moly whack a moley, it was an ID ten T error!

Hello! We had a similar project that is now temporarily frozen for good reasons: in real life the ability of the "AI"s to guess successfully the real destination from analysis of the VPN tunnel traffic is poor (the excellent success rates you see are achieved only in a controlled environment where the victim visits only destinations pre-determined from a tiny list) AmneziaWG is quickly becoming (*) a more universal approach that may be effective and that does not require our own proprietary solution, provided that constant rate tunnel, deterministic batching and traffic morphing are not required -- safe assumptions as DAITA doesn't aim at obtaining them (*) While early AmneziaWG releases could "only" add junk packets during handshakes, making it not suitable to replace DAITA, AmneziaWG latest release is also capable to perform padding of transport messages and modification of their header range. It can do all of the above, optionally, over a faithful imitation of a different protocol (any protocol that can be built on UDP), including specific HTTP/3 web sites initial flow mimicry. While these options efficacy in fighting AI guided traffic analysis must be verified in a controlled environment when AI abilities will improve, and in spite of the fact that AmneziaWG currently lacks the important active distortion feature that DAITA offers, together with reason 1 they are sufficient to let us prioritize AmneziaWG support in the infrastructure and our software, and freeze proprietary solutions research. Once AmneziaWG is operating in the whole infrastructure, it may be considered whether adding active distortion to match this DAITA feature, or anyway building additional features to outperform DAITA (on top of the many already available in Amnezia and not from scratch), is worth the effort or not. Kind regards