Staff

Not so simple in the UK, at least for sites that are willing to comply with the fringe lunatic Ofcom obligations: you need to prove your age by sending the scan of a valid ID document, by paying with a credit card proving that you are 18 or over, or by verifying your age by sending your photo (with strong compliance against fake photos, similar to what you do with banks) for facial estimation (other privacy invasive methods are allowed): https://www.bbc.com/news/articles/c1k81lj8nvpo Porn sites are also obliged to refuse connections from VPN, Tor and proxy. Similar legal frameworks (but theoretically less privacy invasive) are being discussed in the USA and in various EU countries. Kind regards

Hello! To clarify the matter for reader's comfort, there was only one problem: Eddie refusing to start apps not owned by root. The message "No port(s) open" is correct, as it is thrown when the device linked to the port(s) is not connected (or when the user disables the port forwarding for that port on the port control panel). Kind regards

Hello! It is normal with most (or all?) listening programs. They need an incoming unsolicited connection to determine that they can receive it, otherwise they obviously can't know (*). Therefore the decision of most designers is showing the port firewalled until evidence of the contrary comes in. Kind regards (*) unless they maintain an external infrastructure, have the client contact this infrastructure, tell it to send an incoming packet to verify... questionable and probably not worth the effort especially with a p2p software.

Hello! We're very glad to inform you a new 10 Gbit/s full duplex servers located in Stockholm, Sweden, is available: Segin. It will replace, with a more powerful hardware, Ain. Ain will be decommissioned on 2025-08-18. The AirVPN client will show automatically the new server; if you use any other OpenVPN or WireGuard client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637, 47107 and 51820 UDP for WireGuard. It supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the status as usual in our real time servers monitor : https://airvpn.org/servers/Segin Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN Staff

Hello! We're very glad to inform you a new 10 Gbit/s full duplex server located in Bucharest, Romania, is available: Nembus. The AirVPN client will show automatically the new server; if you use any other OpenVPN or WireGuard client you can generate all the files to access them through our configuration/certificates/key generator. The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637, 47107 and 51820 UDP for WireGuard. It supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the status as usual in our real time servers monitor : https://airvpn.org/servers/Nembus  Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN Staff

Hello! We're very glad to inform you a new 10 Gbit/s full duplex server located in Miami, Florida (USA), is available: Dziban. The AirVPN client will show automatically the new server; if you use any other OpenVPN or WireGuard client you can generate all the files to access them through our configuration/certificates/key generator. The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637, 47107 and 51820 UDP for WireGuard. It supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the status as usual in our real time servers monitor : https://airvpn.org/servers/Dziban Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN 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