Staff

Hello! Please be informed of the following, unavoidable scheduled power maintenance in Tokyo needed by our provider to maintain/replace Automatic Transfer Switch (ATS) systems. Start: Thursday, August 14th, 2025, 02:00 local time (UTC+9) End: Thursday, August 14th, 2025, 03:00 local time (UTC+9) The expected downtime is 30 minutes anywhere in the above mentioned time frame. The downtime will affect every and each server in Tokyo. Kind regards & datalove AirVPN Staff

@jedevnull Hello! Please make sure that the directives airusername and airpassword are correctly set in /etc/airvpn/bluetit.rc. Please check the manual: https://airvpn.org/suite/readme/#bluetit-configuration To have Bluetit start and connect during the system bootstrap, please see here: https://airvpn.org/suite/readme/#automatic-connection-at-boot-or-startup-time The AirVPN Suite User's Manual has been compiled with care and it's your friend. If you have already set all of the above and you still experience problems, please send us the Bluetit log too. Example: sudo journalctl | grep bluetit > bluetit.log Kind regards

@ThisisGabeB Hello! Before anything else, please discern whether the problem is caused by a failed WireGuard connection or not, by connecting WireGuard directly from the host, because similar problems which were initially thought as GlueTun bugs: https://github.com/qdm12/gluetun/issues/2458 turned out to be unrelated to GlueTun. Also check this one, just in case it helps: https://github.com/qdm12/gluetun/issues/2516 Read in particular this answer https://github.com/qdm12/gluetun/issues/2516#issuecomment-2602591109 Kind regards

Hello! In general you don't need IPv6 support by your ISP, but only by the system. Once connected you can use IPv6 (which will be tunneled over the VPN IPv4 connection) if needed. Kind regards

@alfavpn Hello! We see that most disconnections are either caused by an "unexpected status" or an "inactivity timeout". Sometimes you have 3 or more hours of continuous connections, sometimes only 45 minutes, so the matter is puzzling especially since you are connected via Ethernet (and therefore you suffer none of the problems caused by WiFi). What happens if you connect via WireGuard, and via Hummingbird? Do you see any difference? Kind regards

Hello! If Eddie is not running, system DNS addresses are correctly set and the firewall is disabled, then the connection inability must have a completely different cause and Eddie has nothing to do with it. Kind regards

Hello! For a quick discernment test please disable the firewall. You can turn off the firewall from the System Settings -> Network -> Firewall option. If the problem gets resolved then you know that it is related to the current firewall rules. In this case, please see also: https://support.apple.com/guide/mac-help/change-firewall-settings-on-mac-mh11783/mac If the problem doesn't get resolved, DNS settings must be checked as well. Please see here: https://airvpn.org/forums/topic/73821-cant-connect/?do=findComment&comment=253454 Kind regards

Hello! Your listening program does not reply to IPv6 packets, but only to IPv4 ones. Check the program settings and also verify that the program supports IPv6 and that the system firewall does not block unsolicited incoming IPv6 packets. Kind regards

Hello! Please make sure that Eddie is not running, check your system DNS settings and set publicly reachable DNS servers. We usually recommend Quad9: 9.9.9.9 149.112.112.112 2620:fe::fe for their commitment to privacy and neutrality. How to change DNS settings on macOS: https://support.apple.com/guide/mac-help/change-dns-settings-on-mac-mh14127/mac Kind regards

Hello, for the readers, explanation of the cause of the problem and quick solution on systems running firewalld: https://airvpn.org/forums/topic/70164-linux-network-lock-and-firewalld/ Kind regards

@jdelliott Hello! Thank you, we will investigate. It looks like the server sends IPv6 push even when UV_IPV6 environment variable is not sent out by the client. In the meantime can you please check a connection over WireGuard? Since there is no push with a WireGuard connection, but all the addresses must be set earlier on client side, the problem should not occur. Kind regards

Hello! No, do not get confused by the VPN subnet on the virtual interface. Thank you for your suggestions, they will be considered. Kind regards

@qwortz Hello! Well, allowing IP forwarding between different subnets could be deemed as beyond the scope of the allowprivatenetwork directive and could be criticized as a source of hazard. We will consider the matter carefully. Kind regards

Hello! Can you please tell us your Linux distribution name and version and send us the Bluetit log taken after the problem has occurred? sudo journalctl | grep bluetit Can you also check whether firewalld is active in your system? Kind regards

Hello! You must always check your facts, before posting publicly on important matters. As far as we can see, according to web searches and AI answers: And of course they are forbidden by the ToS that every AirVPN user accepts. Kind regards

Hello! If you have persistent network lock set on /etc/airvpn/bluetit.rc that's expected behavior: the persistent network lock must remain on even after you voluntarily disconnect from the VPN. You may consider to disable it. However, if you turn off Bluetit completely (for example with "sudo systemctl stop bluetit"), network lock will be disabled in any case. The directive managing persistent network lock behavior is "networklockpersist". Kind regards

Hello! Thanks a lot, we managed to reproduce the problem, it must be a bug: we are investigating. It occurs when you select country GB (United Kingdom) and you are also in the United Kingdom according to Bluetit detection or your declaration on the run control file. The error message is very misleading. More in general, the error occurs when you declare a country and then you try a connection to that same country with --air-country option. A fix will require a new quick release, but in the meantime please resolve the problem by editing your /etc/airvpn/bluetit.rc file with any text editor with root privileges. Declare that you are in any country where we have no servers with directive "country". For example: country IT Then restart Bluetit and try again to connect with --air-country gb option and you should see that the problem is resolved. As an alternative solution, do not set country directive, instead set the following directive, again on your /etc/airvpn/bluetit.rc forbidquickhomecountry no and restart Bluetit. Kind regards

@BigX Hello! At a first sight this problem seemed not reproducible but we found that there's a non-printable character after gb in your command, at least in the command you published (hopefully it is a faithful copy & paste from your terminal/console), so Bluetit looks for gb<feff> which doesn't exist and prints out the error message, where you can't see the non-printable character after gb. Try to enter a "clean" command and check whether the problem gets resolved. Can you also tell us which char encoding you use in your terminal? If the problem persists, can you please try also: goldcrest --air-connect --air-country "United Kingdom" Kind regards

Hello! Unfortunately this is most probably the cause of the problem. Please follow this thread to circumvent the blocks. Each ISP may apply different blocking techniques so an universal solution is not available. You may need to test various connection modes: https://airvpn.org/forums/topic/59479-block-vpn-in-russia/?do=findComment&comment=233388 Kind regards

@PANDABOY Hello! Thank you very much! After your guide has been tested, we are going to split your message in the "How To" forum and make it a guide for Plex remote access via Proxmox on AirVPN. Kind regards

@alfavpn Hello! We're glad to know that the problem was solved through WireGuard and smaller MTU. The website you mention does not allow connections from datacenters; for that we're afraid we can't offer any solution. If you need to buy tickets or access train information you have to proceed without a VPN. Kind regards

Hello! Eddie runs correctly, the problem that causes the disconnection is related to: . 2025.07.26 19:50:30 - OpenVPN > AEAD Decrypt error: bad packet ID (may be a replay): [ #161361 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings Decrypt errors hint at forged packets injection attempts (replay attacks), "dirty" line, MTU related problems... as a first attempt, what happens if you switch to WireGuard (you can do it in Eddie's "Preferences" > "Protocols") with an MTU of 1280 bytes? Please change WireGuard interface MTU on Eddie's "Preferences" > "WireGuard" window. Kind regards

@alfavpn Hello! Are you running the Eddie version built for macOS Catalina and newer versions? Big Sur is still supported by Eddie. Disconnections could be unrelated to software compatibility, can we see a system report taken after a problem has occurred? Please see here: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Kind regards

Hello! Yes, this is a famous trial. It is obvious if you think about it and does not require any AirVPN co-operation. If you read all the court papers (publicly available) the alleged criminal was already a primary suspect so FBI worked to show in court that each time a crime was perpetrated through an IP address assigned to AirVPN infrastructure, the suspect was connected to some IP address of AirVPN (even though different, of course). To make things definitely worse for the suspect, he mixed identities, infringing one of the few "golden rules" (stating that you must NEVER mix identities), by connecting to his own bank account and his own iTunes account with real identity from the same AirVPN IP address (the same exit address the crimes were committed from, with strong time correlations)! Compelling clues which, together with another key finding, convinced the court that the suspect was indeed the culprit. Luckily for the justice (and unfortunately, under his point of view!) this criminal committed serious fundamental errors. Yes. But if one mixes identities the hazard remains high. In this case, it was totally unnecessary. It would have been a huge effort to monitor traffic in 24 different jurisdictions and even more datacenters (normally they do not have access to top NSA tech, as far as we know, and anyway the data collection needed to be admissible in court). In reality, once they had a restricted pool of suspects, they just needed to correlate connections to bank, iTunes (+ social media and any service tied to a real identity of the primary suspects) and victims, and the line (usually residential) used by this pool of suspects. Kind regards

Hello! We're very glad to inform you that Hummingbird 2.0.0 for macOS (Mojave or higher version required) is available. Different native versions for Intel and M1/M2/M3/M4 based Mac computers are available for maximum performance. Hummingbird is free and open source released under GPLv3: https://gitlab.com/AirVPN/AirVPN-Suite Main features Lightweight and stand alone binary client supporting both OpenVPN and WireGuard No heavy framework required, no GUI Small RAM footprint Lightning fast Based on OpenVPN 3 library fork by AirVPN and WireGuard Robust leaks prevention through Network Lock based on pf Proper handling of DNS push by VPN servers New, more flexible Network Lock What's new linked against OpenVPN3-AirVPN 3.12 library all libraries and dependencies have been updated added complete WireGuard support by means of the official WireGuard tools provided by its developers. Installation of wg and wireguard-go binaries is currently required, as WireGuard library is not available on macOS. Please check the user's manual (README.md file included in the packages) WireGuard support section for comfortable, step by step instructions. new Network Lock related options offering more flexibility. Now you can accept or deny incoming, outgoing or both ICMP-echo packets, and independently you can permit or forbid IPv6 NDP, which is based on ICMPv6. The new options supported by Hummingbird (please check the readme file for additional details) are: --allow-ping --allow-ipv6ndp Apple ARM based systems version is now C++20 compliant (required by Sequoia) Important note for high speed line users Because of some architectural specifications and implementation in macOS Hummingbird may warn the user about shortage of buffer space, specifically when connected with the UDP. This condition is signaled by Hummingbird with the below messages in the log: UDP send exception: send: No buffer space available ERROR: NETWORK_SEND_ERROR The error is caused by the maximum network sockets size set in macOS, a value usually small and unsuited for modern high speed networks. The solution consists in increasing the maximum allowed size for socket buffers and, in case the problem persists, the number of mbuf clusters. The procedure is simple, please find out all the details in the manual. Open the README.md file with any viewer and consult the "Note on macOS and UDP" section. Download the software here: https://airvpn.org/macos/hummingbird/ Kind regards & datalove AirVPN Staff