Staff

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

@MyIntertnetSafety Hello! Two potential problems are probably overlapping. For an explanation and a quick solution of the 1st problem please see here: https://airvpn.org/forums/topic/56657-cant-connect-to-anything/?do=findComment&comment=225418 After you have implemented the above fix, please log your account out and then in again from Eddie's main window. This step is strictly necessary every time you renew, delete or add keys for your account. Finally, test again a connection. Kind regards

Hello! We can see your WireGuard sessions on various servers and apparently the system reports them in your account "Client Area" correctly. Do you mean that you are using more connection slots than those appearing in the client area panel? If so, what are the server(s) whose connections from your client(s) do not appear on the panel? Kind regards

Hello! It looks like Kaspersky's servers distributing updates block some AirVPN servers. Do you still experience the problem on any AirVPN server, or only on the USA ones? Kind regards

Hello! Yes, definitely, if you can run traceroute please do it and feel free to send us the whole output. It is probably the best way to understand the whole matter. Excellent, we will test and let you know. Point 2 is very re-assuring. Kind regards

Hello! Let's verify before jumping to conclusions. Remember that VPN routing is managed by Android API VPNService, not by the apps themselves. Also, the 1st considered option would be a correct behavior as, according to it, the traffic IS tunneled. Please answer when you have time to the questions. In particular: provide more details to allow us to reproduce the setup and try to understand what happens exactly. Which proxy is it (SOCKS5, HTTP(S)...)? Do you connect over WireGuard or OpenVPN? check what happens with "Always on VPN" and "Block traffic if VPN is inactive" options enabled check what happens with "Always on VPN" disabled and WireGuard app to manage the connection (in place of Eddie) Kind regards

@Lurchi Hello! It could be correct, i.e. it is plausible that the traffic is encrypted & wrapped for the proxy, then OpenVPN/WireGuard library encrypts, wraps and tunnels via VPNService API the traffic to the VPN server, the VPN server unwraps and decrypts for the proxy, finally the proxy decrypts the "final layer" and sends out the traffic to the Internet "real final" destination. A different, less comfortable option is that the Android proxy setup at WiFi level bypasses the VPNService API, but if that happened then the traffic should get blocked by the Android leaks prevention options (but not necessarily by the "VPN Lock" feature of Eddie). Have you enabled "Always on VPN" and "Block traffic if VPN is inactive"? If you provide more details we should be able to reproduce the setup more closely and try to understand what happens exactly. Kind regards