Staff

Hello! Please delete this one too and test again. Kind regards

Hello! Please delete even any *.airvpnbackup file. The previous OS crash must have left a "dirty" status that requires manual intervention. sudo rm /etc/airvpn/*.airvpnbackup If the problem persists please send us the whole content of /etc/airvpn directory: sudo ls -l /etc/airvpn Kind regards

@spinmaster Hello! This lock file is a temporary file created by Hummingbird to mark that the application is running. It is deleted when Hummingbird is shut down. If it exists while Hummingbird is not running the lock file is a "mark" that Hummingbird did not shut down properly (for example it was closed without grace, or it crashed) and it may hint to something that is not working properly. In your case the cause was surely the OS crash: it's normal that Hummingbird could not delete the file. To delete the file, from a terminal: sudo rm /etc/airvpn/hummingbird.lock because the file can be written/deleted only by root. Kind regards

Hello! Yes, when Eddie Android or Desktop editions see that a connection is lost, they update server scores and likely change server (taking into account servers in the white list, if defined, and not considering servers in the black list, if defined). Note for Eddie Android edition: you can configure it to either mimic exactly WireGuard behavior, or having a supervision of the network status beyond the WireGuard one. Kind regards

Hello! Please move here, where you can see the reports from users all around the world: Also, please make sure to open a ticket to troubleshoot. Last but not least please check the "Top user speed" table on the servers status page https://airvpn.org/status Kind regards

Hello! Your refund was requested on Sunday 01 Dec 2024 and delivered on 05 Dec 2024, even before the 5 business days claimed as a courtesy and within the 30 calendar days according to the Terms of Service. Now it's all up to bank / credit card company, typically credit card companies deliver a refund by a merchant in 4-14 business days. Kind regards

Hello! It's not linked against libtorrent (its backend is libTransmission) so our previous speculation is wrong. To discern whether it is a Transmission specific problem, have you tested other torrent software with the same torrents? Kind regards

Hello! This reminds us of an ancient qBittorrent bug that could be caused by libtorrent. Do you run any torrent software based on libtorrent? If so which version? This bug was allegedly fixed years ago... https://forum.qbittorrent.org/viewtopic.php?t=4342 Kind regards

Hello! According to the latest informal survey (just a couple of years old, so it's relevant) the large majority of our "historical" customer base would consider a unique public IP address assigned to each node (temporarily or not) as a sufficient condition to drop the service. In fact there is a difference but to understand it you should be well experienced on how criminal organizations and/or "legal" investigations (legal in quotes because of the way some countries or agencies operate, which is literally terrifying) work to disclose the identity of a VPN user during his/her connections. We prefer not to enter into details here but you will probably get it with some reasoning. Kind regards

Hello! You can do it with AirVPN thanks to the remote inbound port forwarding system which works, and has always worked, equivalently in v4 and v6. If you need to reserve and open more than 5 inbound ports (the current limit per account) please open a ticket, we are getting organized to add more ports per account at a reasonable fee. Kind regards

Hello! Android 14 and 15 and Android TV 14 and 15 do not allow background activities; Android 14 and 15 however do have "Always on VPN", unless deleted by the manufacturer; Android TV 10, 11, 12, 13, 14 and 15 do not have "Always on VPN"; Android TV 10, 11, 12, 13 allow background activities. Therefore: on Android TV 14 and 15 the connection to a VPN during the device bootstrap remains impossible on an un-rooted device (*); on Android 14 and 15 connection to a VPN during the bootstrap is possible in spite of the forbidden background activities, thanks to "Always on VPN"; on Android TV 10, 11, 12, 13, connection to a VPN during the bootstrap is possible in spite of lack of "Always on VPN" feature because background activities are allowed. However Eddie, unlike the other apps you mentioned, will not take advantage of it, due to a coded limitation according to which it doesn't let you configure app start at bootstrap if "Always on VPN" is not available on any Android TV 10 and higher versions and other specific Android versions. This is Eddie's part that needs to be re-designed and re-implemented in order to allow connection at boot on Android TV 10, 11, 12, and 13. (*) Except maybe on specific devices for some manufacturer customization thru apps start managers at boot or anything else Kind regards

Hello! In Europe: the Netherlands, Sweden, Estonia and Latvia are countries without any M247 server at all. On top of that you can also consider a list of all the 10 Gbit/s servers in Europe and build a white list (they are in Bulgaria, the Netherlands, Sweden, Switzerland). None of the 10 Gbit/s servers in Europe is with M247. Finally, you can find other non-M247 servers in Czech Republic, Germany, Spain, Switzerland (but in those countries we also operate M247 server together with various other providers). Can you tell us why you need to avoid M247 servers (performance problems or anything else) if you wish? Kind regards

@cyberslav Hello! For an explanation and a quick solution please see here: https://airvpn.org/forums/topic/56657-cant-connect-to-anything/?do=findComment&comment=225418 Kind regards

Hello! The trick (an idea to be verified) is using the current broadcast receiver, implemented in the app since its initial release, without verifying "Always on VPN" (Eddie should not refuse to be configured to start at boot if "Always on VPN" is not available) . However, this procedure does not work anymore in Android 14 and above, because it is now forbidden to start activities in background. Eddie was planned to pretend "Always on VPN" on various Android versions, otherwise it refuses to start at bootstrap. Since other programs do not verify the activation of that option, they can still start and connect at bootstrap on Android TV 10, 11, 12, 13 versions. By removing "Always on VPN" and preventing background activities Google closed the loophole of automatic VPN connections during the bootstrap which, we suspect, is detrimental for marketing and profiling reasons. The same decision was taken by various Chinese companies even for Android (and not just TV). In Android 14 and 15, the "Always on VPN" option becomes mandatory and it will allow start & connection during the bootstrap even though background activities are not allowed. Therefore the solution cannot be considered as "universal" but yes, we think we can implement it to overcome the current Eddie limitation, at least it will work in Android TV from 10 to 13. Kind regards

Hello! Please test yourself. In general a packet loss must be avoided. Chicago servers have not suffered any attack lately. The New York servers currently suffer a packet loss on IPv6 addresses only. If you don't need IPv6 you can connect to NYC servers. We are investigating the issue with the help of dc techies. Kind regards

Hello! Of course. We will study the matter carefully and we will update this thread. Kind regards

Hello! No, this feature is explicitly blocked for security reasons. It makes a lot of sense in a virtual network where all nodes are identified and trusted, but here it is considered too dangerous. In 2010, during the free beta testing phase, each client could communicate with other clients within the VPN, but an accurate examination and an overwhelming negative feedback from the testers led us to block communications inside the VPN before we went public. Kind regards

Hello! YouTube is perfectly accessible (just tested) while Reddit wants you to login (just tested) according to their policy (any IP address not assigned to a residential ISP, in theory). After you have logged in to Reddit, you have complete access. Kind regards

@tranquivox69 Hello! Eddie can not start and connect during the device bootstrap without "Always on VPN". The fact that OpenVPN for Android can is unexpected, as the mentioned option was deemed as compulsory to connect to a VPN during the bootstrap. Can you please tell us your device brand and model? Kind regards

Hello! We're very glad to inform you that a new 10 Gbit/s full duplex server located in Zurich, Switzerland, is available: Alpherg. 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. Alpherg 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 by clicking the names of the servers. Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN Staff

Hello! If Network Lock is enabled it must be an Eddie display problem. It's odd because it was not observed before and the data should come directly from system tools measuring the tun throughput. We will investigate, in the meantime you are safe, no traffic is going outside the VPN tunnel, provided that Network Lock is engaged (and that no administrator modifies system's firewall rules, obviously). Kind regards

Hello! We're sorry, we do not compile lists, we offer third-party selected ones. Please contact the list's author at your convenience. Kind regards

Hello! We see that the packets are correctly sent to your node on every port but either they get a TCP RST or no reply is received, except for one port (we presume the one that you report as working). We confirm no problems on the server side. On top of the mentioned check list please review again the firewall rules and/or disable any anti-malware or packet filtering tool for a quick test. Kind regards

Hello! No problems are reported on the CH and SE servers and everything appears just fine. What are the listening programs? Kind regards

Hello! We have checked from inside the VPN server you're currently connected to, and the ports are forwarded properly, but by trying to reach your system through the proper ports we always get an almost immediate connection refused. Can you please test different servers and check whether the problem appears on specific servers? If so, can you please give us the list of servers and then add a new WireGuard key and test again with the new key? If the above does not solve the problem, let's go back to the basic check list. Please make sure that: the listening programs are really running and listening to the correct ports the listening programs do not bind to the physical network interface, or any other wrong interface (if a bind option is available in the listening program settings) the listening programs have been launched after the VPN connection had been established successfully no packet filtering tool or antimalware tool block packets to or from the listening programs Kind regards