Staff

@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

Hello! Possible causes: Streaming services (Netflix, YouTube, etc.) often rate-limit or deprioritize known VPN exit IP addresses, or IP addresses assigned to specific ASNs. Speed tests don’t trigger this, but video streams do. Try different AirVPN servers. Too large virtual network interface MTU causing excessive fragmentation, optionally with broken MTU path discovery. Streaming uses sustained flows that are more sensitive to MTU mismatches than bursty speed tests. Shrink MTU to 1280 bytes to check whether you get any improvement. If not, consider MSS clamping, just in case the PMTU discovery is broken upstream (not an uncommon case). Set MSS to 40 bytes less than MTU, for example MTU 1320 bytes, MSS 1280 bytes. On Asus routers you'll need to do this via iptables: as far as we know there's no option to do it on the Web UI. Asus Adaptive QoS or Bandwidth Limiter on the router. Check and disable such tools if they are active. If DNS is outside the VPN but traffic is inside you can hit far-away CDN nodes, causing slow streams. Make sure to enforce strict DNS settings on the router so that it will query only VPN DNS. Kind regards

@lexsilico Hello! Thank you. We now have all the data. We will update this thread when we have more definite information. In the meantime keep using the successful patch you have already applied. Kind regards

@72MqavduqVa286gd Hello! Nothing changed in Eddie's choice order about which firewall utility to run for the Network Lock rules. If both iptables-legacy and nft utilities are available Eddie picks iptables to avoid mixing up nft and iptables rules in various distributions running daemons at startup that, in turn, still run iptables (mixing up nft and iptables causes problems). You may force Eddie to use nft in "Preferences" > "Network Lock" windows, provided that the nft utility is in the command path. However this is probably irrelevant because, for Network Lock purposes, iptables and nft rules are identical. DNS leaks are not strictly related to network lock: we mean that in general there must be no DNS leak with or without Network Lock. Feel free to publish a system report generated by Eddie for further investigation. Kind regards

Hello! Thanks. Now let's see which route the kernel picks to reach WireGuard's EndPoint. Pick a specific server and verify that the connection takes place through wlan0. From your initial message we see that you may have picked a UK server, let's say Arber (entry-IP addresses 3: 141.98.100.148 and 2001:ac8:31:368:e619:164f:9446:ff2e). Connect to Arber (not to UK in general, connect to this specific server) and verify from the log that WireGuard picks wlan0. Disconnect, shut down Bluetit (sudo systemctl stop bluetit), and check the route the kernel picks on its own: ip route get 141.98.100.148 ip -6 route get 2001:ac8:31:368:e619:164f:9446:ff2e Publish the whole output. Kind regards

Hello! Please send also the output of ip a ip route show before you start Bluetit and/or WireGuard. Kind regards

Please re-read. Your question: "any plan ...?". Answer: "Yes ...". Kind regards

Hello! We're glad to know it. Consider that when OpenVPN finds two interfaces with the same default gateway it stops immediately by throwing a critical error due to the ambiguity. Can you publish the system's routing table and the various interface settings before WireGuard is launched? Kind regards

Solution. Kind regards

@lexsilico Hello! You still have the option to configure policy-based routing using ip to force WireGuard traffic to go through a specific interface, regardless of the default gateway metric. This specific configuration must be created by you as you have no options to force Bluetit to bypass WireGuard (kernel) decisions, and you have no option to tell WireGuard to do the same. You can add your command(s) on the PostUp and PostDown directives to ensure the correct interface is used during the WireGuard connection lifecycle. Note that in this case you will have to use your own profile with Hummingbird (or with Bluetit and Goldcrest), and not the AirVPN integrated Bluetit/Goldcrest connection mode. We will also consult with the Suite development team to study your case in more details and we will update this thread if necessary. We do not rule out the possibility to add in the future special options to compile PostUp and PostDown commands directly from within Bluetit run control file (possibly not via Goldcrest because WireGuard runs PostUp and PostDown specified executable files with root privileges). Kind regards

Hello! We already implemented it in 2021. Any domain which must be blocked includes all of its subdomains too. Besides, different matching methods are available for your additions and exceptions: Exact (exact FQDN), Domain (domain and its subdomains), Wildcard (with * and ? as wildcards), Contain, Start with, End with. Kind regards

Hello! Yes, AmneziaWG support on the server side. You do not need handshake and payload packet padding to circumvent blocks in Russia and China. Padding may be instrumental to make destination guessing from traffic pattern more difficult. Kind regards

Hello! The first main problem to resolve is setting a proper DNS that the container can query before the connection is established. Your system can't resolve the domain name of the end point (us3.vpn.airdns.org), so WireGuard does not even try to establish a VPN connection. Note how the service wg-quick@wg0.service exited because of that (temporary failure in name resolution). Please don't send screenshots whenever text is possible and suitable. Kind regards

Hello! We do agree and we are planning to implement on our software per app traffic splitting on Windows too. Currently you can enjoy per app traffic splitting on Linux (AirVPN Suite) and Android (Eddie Android edition). If the machine you use for Steam is based on Linux you can already have per app traffic splitting with our software. If you run Windows, in the meantime you can consider WireSock, which offers traffic splitting and reverse traffic splitting (on an application basis) and is fully compatible with our WireGuard servers. The Configuration Generator will generate the profiles you wish. Kind regards

Hello! Yes, it is definitely planned, but we can't give you a definite ETA. In the meantime, if you have an Android device or an Android emulator, you can use Eddie Android edition to generate configuration files (you can export them to any other system directly from Eddie's "Export" or "Open with" functions) or the Amnezia configuration patcher by @zimbabwe https://github.com/zimbabwe303/awg_conf_patch Eddie Android edition includes 30+ CPS pre-sets of real web sites, so this is the recommended solution currently to bypass blocks. Kind regards