Staff

Hello! We can't provide an ETA right now but stay tuned. Are you sure that blocks from Russia are effective when you use QUIC CPS of a real .ru website? According to a few reports, that's good to bypass current blocks. However, it must be said that different ISPs implement different blocking techniques. Kind regards

Hello! Syntax error. Check our previous message and fix accordingly, there's an undue space character between "Nftables" and "TableOwner" that must be deleted, otherwise the option is not recognized. Kind regards

Hello! We already told you where to look at and you already provided evidence of the duplicate and exposing Bluetit's bug, don't worry and thank you. No further action is required at the moment. You must see that Bluetit's warning about exclusive tables ownership disappears and Network Lock now works properly. firewalld exclusive tables ownership prevents Network Lock from working properly on any Suite version, obviously. Kind regards

Hello! Exactly. Add it (you can edit the file with any text editor with root privileges), set it to "no" and verify that the issue gets resolved. NftablesTableOwner=no then re-start firewalld. This is vital to let Bluetit operate "Network Lock" properly. Exclusive ownership of the firewall tables must be pondered on a case by case basis. In this case if you wish to enable "Network Lock" you can't assign exclusive ownership of the tables to firewalld. You have two default routes via 192.168.178.1 on the same interface (enp6s0), one without explicit metric (so metric 0) and one with metric 100. Such duplicates are harmless in general but Bluetit detects them, probably fails to understand that the metric of one of them is 0, and throws a critical error believing that the metric is the same for both. We'll work on the matter carefully. In the meantime just delete the duplicate route and configure your interface either fully static or fully DHCP to keep on testing Kind regards

@colorman Hello and thank you for your tests! This is a critical situation which will cause Network Lock to falter and lead to firewall system settings restore problems. Please fix it according to the quoted instructions. Should you have already adhered to the aforementioned guidance and Bluetit continues to issue that warning, we kindly ask you to apprise us forthwith. This critical error suggests that something goes wrong in Bluetit's gateway(s) detection. Probably the error shall endure even after the prior misconfiguration has been rectified. If so, please send us the output of the following commands: ip a ip route show ip route get 0.0.0.0 Kind regards

Hello! This message has been picked to experiment answers by a selected LLM. The answer has been verified manually and slightly edited. In short, the hops you mention are in Singapore. No changes in Singapore infrastructure took place to justify the change in latency you detect. Operator: locate countries of: vlan12.as06-10g.wco1.sg.m247.ro irb-1906.agg1v.wco1.sg.m247.ro be-2-3111.bb1n.wco1.sg.m247.ro All three hostnames point to infrastructure in Singapore. Here’s how that breaks down: wco1.sg.m247.ro sg is the standard country/location code for Singapore wco1 likely refers to a specific data center or site within that region m247.ro is a Romanian network provider (M247), but they operate globally So for each: vlan12.as06-10g.wco1.sg.m247.ro → Singapore irb-1906.agg1v.wco1.sg.m247.ro → Singapore be-2-3111.bb1n.wco1.sg.m247.ro → Singapore Summary: All three are part of M247’s network presence in Singapore, despite the .ro domain. Operator: Break down names with additional details These hostnames follow fairly typical ISP / backbone naming conventions. Each segment encodes device role, interface, and location. Let’s break them down piece by piece. 🌍 Common suffix (applies to all) m247.ro → Network operated by M247 (Romanian-origin ISP with global PoPs) sg → Singapore wco1 → Likely “West Coast / core site 1” (internal site code for that Singapore PoP) So all three are devices inside the same Singapore location. 1️⃣ vlan12.as06-10g.wco1.sg.m247.ro Breakdown: vlan12 A VLAN interface (Virtual LAN ID 12) Used for logical segmentation inside a router/switch as06-10g as06 → likely “access switch / aggregation switch #6” 10g → 10 Gigabit interface/uplink wco1.sg.m247.ro Location + provider (Singapore PoP) Interpretation: 👉 A VLAN interface (ID 12) on an access/aggregation switch with a 10G link 👉 Likely used for customer traffic or internal segmentation 2️⃣ irb-1906.agg1v.wco1.sg.m247.ro Breakdown: irb-1906 IRB = Integrated Routing and Bridging Interface number 1906 Common on Juniper gear (Layer 3 gateway for a VLAN) agg1v agg → aggregation router/switch 1 → device number v → possibly “virtualized” or variant of the node wco1.sg.m247.ro Same Singapore site Interpretation: 👉 A Layer 3 gateway interface (IRB) on an aggregation router 👉 Handles routing between VLANs or customer subnets 3️⃣ be-2-3111.bb1n.wco1.sg.m247.ro Breakdown: be-2-3111 BE = Bundle Ethernet (port-channel / LAG) 2 → bundle ID 3111 → internal interface identifier bb1n bb → backbone router 1 → device number n → possibly “north” (directional naming is common) wco1.sg.m247.ro Same location Interpretation: 👉 A backbone router interface using a bundled (aggregated) high-capacity link 👉 Likely part of core transit or inter-PoP connectivity 🧠 Big picture (network hierarchy) Putting them together: Access layer → as06-10g (customer-facing / edge connectivity) Aggregation layer → agg1v (traffic consolidation + routing) Backbone/core layer → bb1n (high-capacity transit) This is a classic ISP architecture: Customer VLAN → Access Switch → Aggregation Router → Backbone Router ⚠️ Important note These interpretations are informed guesses, not guaranteed facts. Naming conventions vary by provider, but M247’s style aligns closely with standard ISP practices. Kind regards

@anchoby Hello! Error 111 means that the packet reached your node but the attempted connection was actively rejected, typically through a TCP RST packet. Please follow this checklist: https://airvpn.org/forums/topic/66388-port-forwarding/?do=findComment&comment=243305 Kind regards

Hello! We see the problem. Eddie Android edition 4.0.0 is affected by a bug. When Eddie generates a profile for WireGuard or AmneziaWG, it fails to add the MTU option and the IPv6 argument for the AllowedIPs option. We have immediately patched Eddie with high priority and now version 4.0.1 is available, addressing these issues. We strongly recommend that you upgrade immediately. Thank you for having reported the problems! Please see also here: https://airvpn.org/forums/topic/80030-eddie-android-edition-401-available/ Kind regards AirVPN Support Team

Hello! We're very glad to inform you that Eddie Android edition 4.0.1 is now available. This is a patch release to fix a bug affecting AmneziaWG and WireGuard profile generation by Eddie. When generating a profile for WireGuard or AmneziaWG, Eddie 4.0.0 omits the MTU option and the IPv6 address space (even when it's necessary) in AllowedIPs option arguments. We strongly recommend that you upgrade immediately. Eddie Android edition 4.0.1 is available on our web site and the Google Play Store. Any other feature is described by the 4.0.0 version announcement, available here: https://airvpn.org/forums/topic/79743-eddie-android-edition-400-available/ Kind regards & datalove AirVPN Staff

Hello! We're very glad to inform you that AirVPN Suite version 2.1.0 alpha 1 is now available for x86-64 based Linux systems. Builds for ARM architectures will be available in the near future. AirVPN Suite 2.1.0 development focuses on bug fixes, improved IPv6 management and aims at a quick release. New features are planned for the major new version (probably 3.0.0) which is planned to offer complete AmneziaWG support. Main changes: very large routing table should not cause Bluetit to crash anymore more accurate detection of default gateway several IPv6 addresses management fixes more accurate detection of network availability (in progress) Changelog for the AirVPN Suite 2.1.0 (complete file available in the downloadable package): Version 2.1.0 alpha 1 - 23 April 2026 [ProMIND] updated to OpenVPN-AirVPN 3.12 (20260206) airvpntools [ProMIND] added new method capitalizeWord() network [ProMIND] getGatewayFromRouteTable(): msgBuf is now dynamically allocated (currently to 32KiB) [ProMIND] getGatewayFromRouteTable(): socket's receive buffer set to 1MiB [ProMIND] getGatewayFromRouteTable(): revised code for a more strict and reliable scan [ProMIND] added methods isValidIPAddress(), isValidIPv4() and isValidIPv6() [ProMIND] parseIpSpecification(): fixed IPv6 specification handling wireguardclient [ProMIND] setup(): check validity for both IPv4 and IPv6 gateways [ProMIND] profileNeedsResolution(): fixed IPv6 address handling [ProMIND] setConfiguration(): fixed IPv6 address handling [ProMIND] resolveProfile(): fixed IPv6 address handling URL to download the tarball (please note that packages for ARM architectures will be available in the near future): https://eddie.website/repository/AirVPN-Suite/2.1.0-alpha1/AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz SHA-2: https://eddie.website/repository/AirVPN-Suite/2.1.0-alpha1/AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz.sha512 $ sha256sum AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz fcc74f7941b6c1b4215e9820d2fc959fb17957fbbdb7d149a1a128930f05038d AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz If you wish to test, thank you very much! Please feel free to report here any bug and malfunction you find! Kind regards & datalove AirVPN Staff

@lexsilico Hello! We have AirVPN Suite 2.1.0 alpha 1 ready (only for x86-64 systems). It aims at addressing (in this alpha 1 or imminent versions) this problem. Would you like to test it and report back? It also includes IPv6 related fixes, but remember that it's still an alpha version so don't rely on it for serious purposes. ARM builds will be available soon, stay tuned. URL to download the tarball: https://eddie.website/repository/AirVPN-Suite/2.1.0-alpha1/AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz SHA-2: https://eddie.website/repository/AirVPN-Suite/2.1.0-alpha1/AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz.sha512 $ sha256sum AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz fcc74f7941b6c1b4215e9820d2fc959fb17957fbbdb7d149a1a128930f05038d AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz If you test, keep us posted! Kind regards

@Pi77Bull Hello! We have AirVPN Suite 2.1.0 alpha 1 ready (only for x86-64 systems). Although it does not address directly the main problem you mentioned with network gateway check, it is undergoing various changes that could resolve the issue (either in this early alpha 1 version or in the next ones). Would you ike to test it and report back? It also includes IPv6 related fixes, but remember that it's still an alpha version so don't rely on it for serious purposes. URL to download the tarball: https://eddie.website/repository/AirVPN-Suite/2.1.0-alpha1/AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz SHA-2: https://eddie.website/repository/AirVPN-Suite/2.1.0-alpha1/AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz.sha512 $ sha256sum AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz fcc74f7941b6c1b4215e9820d2fc959fb17957fbbdb7d149a1a128930f05038d AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz If you test, keep us posted! NOTE. Before proceeding, make sure that the directory /etc/netns exists on your system. If it does not, create it before testing traffic splitting. Currently, it is assumed that /etc/netns is a system directory on Linux distributions, so, if it was removed, you (as superuser) and not Bluetit must re-create it to let the system (and Bluetit) store configuration files for different network namespaces in isolated directories. Kind regards

@Posh1698 Hello! We have AirVPN Suite 2.1.0 alpha 1 ready (only for x86-64 systems). It aims at addressing this problem. Would you like to test it and report back? It also includes IPv6 related fixes, but remember that it's still an alpha version so don't rely on it for serious purposes. URL to download the tarball: https://eddie.website/repository/AirVPN-Suite/2.1.0-alpha1/AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz SHA-2: https://eddie.website/repository/AirVPN-Suite/2.1.0-alpha1/AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz.sha512 $ sha256sum AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz fcc74f7941b6c1b4215e9820d2fc959fb17957fbbdb7d149a1a128930f05038d AirVPN-Suite-x86_64-2.1.0-alpha-1.tar.gz If you test, keep us posted! Kind regards

Hello! A possible reason is that Eddie generates files compliant to the latest protocol specifications and you are using an older version. If that's the case, we can compare the two different profiles (remember to delete your key), i.e. the working one and the non-working one, and check the log of your software to find out the reason. Kind regards

Hello! You may get a lot of data from here: https://airvpn.org/forums/topic/65417-amneziawg-config-patcher-cps-db/ If you have an Android device or emulator, by running Eddie Android edition 4 you can generate ready to use AmneziaWG configuration files which are fully integrated with AirVPN (i.e. you can generate profiles for specific AirVPN servers, countries and so on), even relying on a large CPS QUIC database of real web sites if needed to bypass the blocks. You can then share them with your Windows machine. Important: Eddie Android edition generates files compatible with v2.0 Amnezia protocol, so you need this latest version. Kind regards