Staff

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

Hello! Yes, the server has been deployed and connected, its system has been installed and we are testing it. If no problems arise during the tests we will make it available very soon. Kind regards

Hello! We post the reply to your ticket by the support team for the reader's comfort. ==== Hello and thank you for your choice! We do not think that the problem can be approached and resolved through OpenVPN configuration files. We would consider policy based routing on the router. In this way you can configure each specific device behind the router to have its traffic routed through the proper tun interface or even through the WAN (outside the VPN, therefore). Please check the documentation. An overview of the Policy Based Routing (PBR) utility: https://openwrt.org/docs/guide-user/network/routing/pbr A specific approach to achieve the setup: https://search.brave.com/search?q=openwrt+policy+routing+for+multiple+OpenVPN+client+connections&summary=1&conversation=f943dbcf532434cd689c65 Kind regards AirVPN Support Team ==== Kind regards

@starl1te Hello! The problem should be Tegmen specific. We have now brought down the server to investigate. Please connect to any other server. Kind regards

@Octopilion Hello! 1. Please upgrade to Eddie 2.24.4 beta and test again. By default 2.24.x will use WireGuard to connect (you can change connection mode in "Preferences" > "Protocols" window, but stay with WireGuard to test). If you still get 200 Mbit/s change WireGuard interface MTU in "Preferences" > "Protocols" window to 1280 bytes. There is no enforced cap on AirVPN, the only limit is the physical limit of server line capacity or the limit of the weakest hop in the route between your node and the VPN server (as usual on the Internet). However, it's not uncommon that residential ISPs apply traffic shaping against specific protocols. Let's see which performance you get with Eddie 2.24 working with WireGuard and whether the traffic counter is more realistic. 2. In order to access your local network with Network Lock on please check "Allow LAN/private" on Eddie's "Preferences" > "Network Lock" window. However, when using WireGuard you might be unable to reach your local network in any case, because Eddie doesn't set the VPN exclusion routes. Kind regards

Hello! It is unexpected. Is "Network Lock" on (if not, please test also with Network Lock enabled)? Which Eddie version are you running? Can you also tell us your Operating System name and version? Kind regards

Hello! According to several reports available on the www, a few years ago this did not happen on iOS. The problem was typically the opposite, i.e. how to reach the local network while a WireGuard connection is active. A plausible explanation is that more recent iOS [VPN API] versions keep a route to the default gateway with a longer prefix for the local network. The route with the longer prefix (for example /24 instead of /0) always takes the precedence on nowadays systems. Please see also: https://www.procustodibus.com/blog/2021/03/wireguard-allowedips-calculator/ However, we could not find this behavior documented. Does any reader have a link to some official documentation by Apple about all of the above? Kind regards

Hello! If it's not a browser problem and you need Google Search please try https://startpage.com - it will proxy your queries to Google Search and give you back the exact Google Search answers. If possible avoid Google and use different search engines that don't track & profile you and don't harvest data such as Brave Search (which also features a free AI by default that's not bad): https://search.brave.com Kind regards