Staff

@irxhnfdptv Hello! WireGuard can't connect. Might it be blocked in your network? If you try a connection with the native WireGuard client for Linux, is it successful? You can generate a profile for WireGuard on our Configuration Generator available in your AirVPN account "Client Area". By testing the WireGuard client directly you may let us discern whether the problem is Bluetit-specific or not. Kind regards

Hello! The main reasons: for companies whose core business is based on personal data harvesting and reselling (with or without the consent of the data subject) VPNs are a part of a serious threat e-commerce companies consider connections from VPNs more risky for fraud attempts by the hobbyist, implementing a generic black list which includes VPN and Tor exit nodes IP addresses may be seen (probably wrongly we dare to say) as an added security filter against cracking attempts Kind regards

Hello! The web server might bind to any interface so please make sure that you keep our software "Network Lock" option enabled to prevent any traffic leak outside the VPN tunnel. Kind regards

Hello! @cccthats3cs Thank you very much, those documents are interesting indeed. All the matter is indeed a risk which we warned our users about according to their threat model since AirVPN's birth. The described investigation techniques may be instrumental to bring to justice criminals without enforcing provider to blanket data retention, and therefore they show once again the correctness of the Court of Justice of the European Union which forbade repeatedly EU Member States to oblige any ISP to perform blanket data retention. We're also pleased to see that AirVPN made no technical mistake instrumental to the suspect's incrimination and that a "trap and trace" device had to be physically installed outside AirVPN servers Unfortunately the same methods might also be used by powerful crime organizations or agencies of regimes hostile to human rights to find out and suppress activists, "dissidents" and limit freedom of expression and information. For this reason we wrote extensively about how to defeat easily such powerful adversaries (provided of course that your system is pristine, not compromised, an essential pre-requisite). In 2012 we published this for example: https://airvpn.org/forums/topic/54-using-airvpn-over-tor/?tab=comments#comment-1745 Multiple times we warned about the danger of "black boxes" and it's not incidental that "OpenVPN over Tor", for example, has been implemented in our mainstream software since 2011 or 2012 and it is advertised in the home page while Tor is also listed in the "Download" > "Other technologies" section. Kind regards

Hello! We inform you that the following servers are being withdrawn: Servers: 1+1 Gbit/s Alkes, Merope, Sabik (Los Angeles, California) Reason: not meeting our requirements anymore for hardware and lines. Replacement: yes, two 3+3 Gbit/s servers in San Jose (California), planned for January the 14th 2024 or earlier, on top of the new (already active) 10 Gbit/s server in Los Angeles (Saclateni). Servers: 1+1 Gbit/s Pollux (Jacksonville, Florida) Reason: not meeting our requirements anymore for hardware and line. Replacement: yes, one 3+3 Gbit/s servers in Raleigh (North Carolina, planned for January the 16th 2024 or earlier) + expansion in Miami planned for the near future. Kind regards and datalove AirVPN Staff

Hello! This is an ancient problem on some very old Eddie version (2.18), while the forced shut down is CORRECT AND EXPECTED if you don't disable the exit confirmation prompt, do you really have an identical problem with latest releases? Please open your own thread and also open a ticket (attach a system report, please). The problem might be slightly different or the same or it could be just an expected behavior, in any case this is probably not the correct thread. Kind regards

Hello! Please see here for a quick and easy solution: https://airvpn.org/forums/topic/56643-stuck-in-a-broken-route-never-connects/?do=findComment&comment=225323 Kind regards

Hello! Please jump to the thread linked by @monstrocity for a variety of workarounds and some explanations. In this very moment you can access Reddit from Netherlands, Switzerland and other Europe VPN servers, even without logging in. From other servers you will need to log in to Reddit to be able to read subreddits. Kind regards

Hello! For the purpose of domain name resolutions, VPN server scores are computed on the following variables: average ping (between VPN servers themselves); average load; average users; known issues; ISP reliability. In the case of Xuange, currently it does not achieve the "best" score in Europe or in Switzerland because the amount of connected users is sufficiently high to outweigh the amount of free bandwidth. Kind regards

@dersik Hello! The problem is under the attention of Eddie's developer. To start Eddie without GUI, please note the "--clie" typo. The correct option is "--cli". You might still experience problems, even without the GUI, but it's worth a test. Do you need to connect over WireGuard or OpenVPN? Kind regards

@supermanvthanos Hello! Set the link MTU size identical to the size set by Mullvad and then increase at little steps. 20 bytes by 20 bytes. Consider that: Mullvad software forces the MTU size to 1280 bytes (at least some time ago, we don't know whether they changed it recently) Eddie 2.21.8 lets WireGuard set the MTU size and it does not offer an option to change it. If WireGuard makes a wrong choice Eddie 2.21 can't fix it Eddie 2.23.x sets MTU size to 1320 bytes but also lets you change it in Preferences > WireGuard window, a new feature. If you want to test it: https://airvpn.org/forums/topic/56428-eddie-desktop-223-beta-released/ if you run native WireGuard utilities you can change MTU size by entering the directive MTU = n, where n is in bytes, in the [Interface] section of the configuration file. You can edit it with any text editor each time you change MTU size you must re-start the connection to apply the change. Perform the speed tests to fine tune and find the optimal MTU size for your network. Rationale: too small and too big MTU sizes deeply impair performance. In the first case there's a waste of room in the frame, in the second case a whole packet must be re-sent for each packet too large for the frame. Feel free to open a ticket if you need support directly from the AirVPN support team. This is the community forum so it's not the proper place as the community can't do anything about it obviously. If you decide for a refund you will need to open a ticket (click "Contact us" on the web site or write to support@airvpn.org). Kind regards

Hello! You can always know for sure that your web traffic and any other traffic did not leak, provided that you enable "Network Lock" option in Eddie. This feature is a set of firewall rules, so even if Eddie crashes you know that no leaks can occur (unless you reset the firewall rules with root privileges, of course ). Yes, it seems comfortable. Actually, you don't even need double hop and a SOCKS proxy to exit on different countries with different containers. You may connect directly each container to a different country server without double-hop and therefore you will have remarkably higher performance on each tunnel and for the whole container, so you are not limited to a single program, and you are not limited to TCP (and not even limited to WireGuard, just in case you need OpenVPN for some blocking or other reason). The limit is 5 concurrent connection slots, which should be anyway enforced to prevent "infinite account sharing" of course. On the other hand, switching proxy directly from inside Firefox is faster if you need only Firefox and the useless double hop performance hit may appear as a fair price to pay. Currently you can do it in AirVPN but with external proxies, since we have no plans to operate directly SOCKS5 proxies at the moment. The proxy will anyway see only the VPN server exit-IP address and together with end to end encryption you would be fine. Kind regards

Hello! The Kaspersky VPN interface causes a critical error to OpenVPN: To solve the problem please set Eddie to ignore any alien interface: Select from Eddie's main window Preferences > Networking, write eddie in the "VPN interface name" field click Save. You may also consider to switch to WireGuard to bypass the alien interface. You can do it in Preferences > Protocols window. Uncheck Automatic, select a WireGuard connection mode and click Save. Kind regards

Hello! Effective "Kill switches" are available in Merlin WRT (set Block routed clients if tunnel goes down option to Yes), Tomato and DD-WRT (check Killswitch box). On older OpenWRT versions and other routers supporting OpenVPN or WireGuard you can implement a "kill switch" via specific rules once and for all. The additional SOCKS proxy connection you mention based on SOCKS proxy available inside the VPN does not solve the leaks hazard. It may prevent leaks only for those applications which are explicitly and manually configured to connect to the proxy inside the VPN. Any other application and especially any system process will not have such protection. It is advisable that you enable a proper method of preventing leaks, which will take just a few seconds and is explicitly implemented in any modern router firmware, instead of this somehow flimsy and partial "solution" which is not and should not be advertised as a general traffic leaks prevention method and which provides a false and therefore dangerous sense of security, as your own message hints to. Furthermore, Mullvad introduced this complication in order to be able to guarantee that you always appear on the Internet with the same IP address when you connect to the same VPN server and when an app will "proxy" the traffic. That's not necessary in AirVPN where you already and always have the same public IP address when you connect to the same VPN server. Kind regards

Hello! Can you publish or send through a private ticket a system report generated by Eddie (the Air software client) just after the problem has occurred? Please see here to do so: Kind regards

Hello! Latest Eddie 2.23.2 has been tested publicly for such a long time that we would say that you can safely run it. If you prefer to stay with 2.21.8 then you can consider to disable systemd-resolved which is the cause of the leaks you mention when it works in on-link mode bypassing resolv.conf file. While Eddie 2.23 and the AirVPN Suite for Linux offer full support with proper DNS management for every systemd-resolved working mode, Eddie 2.21 doesn't. Kind regards

Hello! Quick preliminary check, just in case: https://airvpn.org/forums/topic/56912-black-friday-ad-stops-connection/?do=findComment&comment=227088 Kind regards

Hello, we're glad to inform you that we will be launching a 3 Gbit/s full duplex guaranteed (on a 10 Gbit/s port, burstable) server in North Carolina around mid-January, please stay tuned. Additional expansions in Florida and Georgia will be under discussion later on, as usual according to bandwidth demand. Meanwhile, expansion on the other side of the USA (California) is ongoing: after the recent 10 Gbit/s addition in Los Angeles, two more 3 Gbit/s servers (burstable to 10 Gbit/s) are expected in San Jose for mid-January. They will replace the current three 1 Gbit/s servers in California marked with "Imminent withdrawal". Kind regards

@foDkc4UySz Hello! WireGuard is the default choice in Eddie Android edition and it will be in the next AirVPN Suite for Linux (you can see the AirVPN Suite 2.0.0 preview version which is already supporting WireGuard fine). On Eddie Desktop edition the matter will be thoroughly discussed. On one hand you have the poor performance on networks shaping WireGuard, the complete WireGuard block in countries which are not irrelevant for AirVPN, together with the privacy problems posed by WireGuard. On the other hand you have the superior performance of WireGuard in agnostic networks and the fact that the privacy problems are mitigated by our setup and can be resolved by your behavior (key renewals). Plus, it must be taken into consideration the fact that if UDP is de-prioritized, then even the default OpenVPN on UDP of Eddie Desktop edition will suffer just like WireGuard. Kind regards

Hello! We could not reproduce the problem in any time period of the day in the last 4 days, when this thread started, thus we could not and did not do anything. Glad to know that it's back to normal for you, we'll keep an eye on it. Kind regards

Hello! In Singapore complaints against the servers are sometimes treated blindly without giving us enough time to reply and therefore IP addresses are null routed. When this happens the unblocking procedure may take time. Additional problems have included IPv6 network and line problems. Such problems may occur now and then even in any good datacenter. If the servers keep failing the expectations, as your complaints suggest, we will dismiss them and search for an alternative. It's not so easy in Singapore for the high volume traffic we require, so the matter is not trivial. Anyway, we already operate both on Leaseweb and M247 datacenters in Singapore, so we already offer redundancy. Kind regards

Hello! We're sorry, the new servers will not keep the same IP addresses. Kind regards

Hello! The "Client Area" session(s) panel shows the current connection slots, while the web site "Account Settings" > "Recently used devices" panel shows a part of the account's browser user agent transmitted to the web site when you log in to it. Kind regards

Hello! Please try to delete Eddie's configuration file while Eddie is not running and test whether the problem gets solved. Please see the following linked page in order to find the location of the configuration file: https://eddie.website/support/data-path/ Kind regards

Hello! While this idea came to our mind too, although it's not anywhere in the contractual agreement, we probably have to rule it out as well, because in peak times you still have more than 600 Mbit/s in upload, which for the server means receiving 600 Mbit/s and sending out (virtually at the same time) 600 Mbit/s, so neither the incoming nor the outgoing bandwidth suffers congestion. However when you download you have very poor speed. although for the server the operation is "symmetric" to the previous one, it requires exactly the same bandwidth both in and out. So we have thought about a congestion in your network, but that's also to be ruled out otherwise you would have poor performance on the NL servers too. The only remaining and realistic option on congestion considerations we can think of is that some transit node in between you and M247 is congested on peak times and only on one direction. We will perform additional tests in an attempt to understand the possible cause of the problem. Kind regards