Staff

Hello! We're sorry, no news. Google blocks some of our VPN servers as well as VPN servers of our competitors. Moreover, some servers are not blocked, but it's the Google's authoritative DNS that blocks our DNS servers, so we have two different approaches to sabotage VPN access. That's understandable as a widespread usage of VPN, Tor etc. is a threat to Google core business, which is also pushing its own VPN in an attempt to stop the threat. Google services must never be used and if you share our mission you should avoid them at all costs, but if you want to access them from the VPN you may consider to contact Google and send them your complaints. For Google Search consider startpage.com (which helps mitigate Google Search tracking) or switch to some better search engine which does not harvest your personal data such as https://search.brave.com Kind regards

Hello! UDP (the protocol used by OpenVPN) is blocked, or OpenVPN traffic itself is blocked Usually the block comes from a packet filtering tool or an antimalware integrated tool. Since the error says "operation not permitted", the block is most likely enforced on the same machine which also runs Eddie and OpenVPN. Please check any mentioned tool and remove the block. OpenVPN may operate in TCP too, but we recommend that you remove the block because OpenVPN is more efficient in UDP and also because you can run WireGuard which can work only on UDP. In Eddie, you can switch to WireGuard from the "Preferences" > "Protocols" window, after you have unchecked "Automatic". Kind regards

Hello! Please read: https://airvpn.org/faq/port_forwarding/ and: https://airvpn.org/faq/p2p/ Kind regards

@MelonPan Not the user agent (a user agent is a different thing) but the program name and version if your program sends it. Yes, it's an information voluntarily sent by your program. If your program does not tell the server anything, this information is not available. It is meant for your comfort so you can discern and identify your devices and programs used for each connection slot in your "Client Area" at a glance. Sometimes useful for self troubleshooting too. For example seeing an alien OS that you don't run using one of your account connection slots to some server that you don't connect to may suggest something. In general very useful, not creepy at all. About the IP address, @SurprisedItWorks and @OpenSourcererexplained already, we just add that knowing the destination address is strictly necessary for every application in every network based on IP (Internet Protocol), it's not some "special" requirement of OpenVPN, WireGuard or whatever. Kind regards

Hello! You are and were correct, you can also see here the announcement: https://airvpn.org/forums/topic/56495-servers-power-up-shown-in-the-web-monitor/ Kind regards

Hello and thank you for your choice! We will have Eddie's developer investigate the issue. In the meantime please try the following settings to solve the problem: from Eddie's main window select "Preferences" > "Advanced" uncheck "Check if the VPN tunnel works" click "Save" from Eddie's main window select "Preferences" > "DNS" uncheck "Check Air VPN DNS" click "Save" from Eddie's main window enable "Network Lock" try again connections to various servers We're looking forward to hearing from you. Kind regards

Hello! Yes, what you write is substantially true, although a server reboot is not needed. The matter has become a FAQ and we added an answer to this FAQ here: https://airvpn.org/faq/wireguard/ In the answer you can see how we patch a specific problem, how you can act through our tools to improve your privacy when you run WireGuard, and all by not breaking original WireGuard compatibility. However OpenVPN under this respect remains widely superior, so consider it according to your threat model and the amount of annoyance you would get to generate new keys after each WireGuard session. Kind regards

Thank you for the important information. Kind regards

Hello! It's possible, as AirVPN Suite 1.3.0 was released on the 7th of June and Network Lock features were extensively rewritten. If you want to go back to 1.2.1 here's the direct link to the tarball for Linux x86-64. https://eddie.website/repository/AirVPN-Suite/1.2.1/AirVPN-Suite-x86_64-1.2.1.tar.gz If you decide to downgrade, please let us know whether 1.2.1 is fine on your system. Also remember to wipe out the whole /etc/airvpn directory and any goldcrest.rc file because some new directives are not supported by 1.2.1. Kind regards

@Gooberslot Thank you for the report. Can you please check whether the same problem persists when you re-enable network lock, but disable ufw completely? sudo ufw disable We ask because we have seen lately strange interactions (probably caused by translation errors) in systems based on nftables (iptables has been left apart by most distributions) when ufw kicks in needing translations and the Suite uses nftables (ufw is a frontend of a frontend of a frontend in this case, because it is able to operate through iptables only and not nftables). After that we will send all the info and report to the Suite developer. Kind regards

We're glad to know that this solution meets your needs. Thank you very much for your choice and your great feedback! Kind regards

@ProphetPX Hello! First and foremost, let's specify that the system names resolution priority is always hosts file before DNS (unless you have deeply tweaked the system, but it's not the case we guess). With that said, you can tell Eddie not to consider the server DNS push and leave your DNS settings unaltered in the "Preferences" > "DNS" window. Set the "DNS switch mode" combo box to "Disabled" and uncheck "Check AirVPN DNS". We don't know how it's possible, according to your description, that DNS push could work if DNS client service was disabled, we leave this part to Clodo. Thank you very much! Kind regards

Hello! For the selection problem, please consider this potential solution in your ovpn configuration file: remote-random remote <country>3.vpn.airdns.org remote <another country>3.vpn.airdns.org ... remote <yet another country>3.vpn.airdns.org where you list only the ISO codes of the countries you want to connect to. Please see also here: https://airvpn.org/faq/servers_ip/ About the connection instability you experience have you examined the OpenVPN log to check whether packet errors are reported (hinting to bad line or MTU size related problems)? If the device is connected via WiFi, try to change channel and/or get a stronger signal. If you suspect that the problem is MTU related, try the following directive (in the ovpn configuration file) and check whether it mitigates the problem: mssfix 1280 Kind regards

Hello! The asymmetry you describe is an anomaly caused by malicious activity which is already foreseen. The upload/download ratio is monitored since 2011. If the absolute value of its difference from 1 is greater than a pre-determined safety parameter the alert system kicks in. The situation takes place only when malicious traffic breaks in through the perimeter defense. Users are alerted by the real time server monitor or by our software accordingly. A server under the condition you describe must not and will not operate. Kind regards

Hello! You have the elephant's memory or you dug into datacenters' features. Let's not exaggerate though, the links are normally two and Juniper or Arista switches can start at 10 GbE, only some are 40 GbE or more. However, the stated bandwidth is guaranteed and dedicated as always. Now that the CPU is no more the first bottleneck, usually the limit is enforced on port. Specifically for AMS-IX we don't know whether our traffic relies on one high speed router or more, last year it was one. The total guaranteed bandwidth we pay for in the Netherlands is currently something around 150 Gbit/s in total. Kind regards

Hello! OK, and please let the community help us understand what customers care about, and let us decide accordingly, especially when hundreds of them asked for this modification. Kind regards

Hello! AzireVPN uses our new method, we see now from their stats. They show bandwidth in and bandwidth out of each server. They don't have graphs, stats by time periods and a ton of other features we offer, but they still show up + down ("in" + "out" in their monitor). Note how it's not symmetrical, showing once again that your solution was indeed inapplicable. For example in this moment they declare that a server in France uses 1200 Mbit/s "in" and 109 Mbit/s "out". They also write: "Each server is connected with two 1 Gbit/s links towards the switch." In iVPN,, oh well... that would be a server monitor in your opinion?! It's a list of servers with a percentage, no stats, no graphs, no history, no nothing... We can't see any provider offering a server monitor like ours. To the best of our knowledge this is a very exclusive feature of AirVPN. So we can't name any simply because nobody has it. But Azire (you mentioned it) adopts the same solution by publishing "in" and "out" flow. As shown by your own Azire example, it wouldn't be accurate. That's of course false. You may have asymmetries which make this quoted statement false. Even a scriptkiddie modest flood counts significantly, in this case, either inside the VPN, or incoming from outside the VPN itself. Publishing raw data as they are is the most reliable way, it's the way recommended by an important amount of community members, and it does not require data manipulation. By clicking the name of the server in our real time server monitor you can still see the distinction of bandwidth "up" and "down" of course, that feature, together with the graphs, remain. Kind regards

No, it's just right, because it shows the maximum capacity of a server line. Can we see the real time servers monitor of other companies showing what you claim? No, we don't account traffic twice, otherwise the load would not be correct. We show the exact throughput (sampled every other minute) on the server. For the top throughput of clients please consult the proper table. The real time servers monitor shows the server status, not your expectations. Your solutions would display false data, while the real time servers monitor displays true data within the boundary of the sampling frequency. Kind regards

Hello! We have merged two threads into this one so you can continue here the discussion and leave the "News" forum more readable. Kind regards

Hello! If you know nothing about networking you would probably ask for information or get informed and then you discover that this is exactly the case. Kind regards

Hello! Sorry, we can't understand you, we just explained why that would not be truthful. Kind regards

Hello! No, it wouldn't be better. Only now the measurement is fully consistent. This measurement system shows you things as they are. The old system added up+down bandwidth of clients, but cut in half the server availability, therefore a server with 1000 Mbit/s in use would look at capacity while in reality it can still give another 1000 Mbit/s - you should see by yourself that this system can't hold. If we kept the old system we would keep receiving (and rightly so) a lot of complaints for servers which seem at capacity or overcapacity while they are not. If we cut the used bandwidth in half, we would rely exclusively on the VPN symmetry, which is not truthful when a server must face floods or non-VPN traffic in general. This is again a community driven request and in this case we share the objections against the old inconsistent system, which made sense when CPU and other bottlenecks capped the server, or when we had 500 Mbit/s full duplex lines. Kind regards

Hello! We're glad to inform you that all VPN servers are now connected to 1 Gbit/s or 10 Gbit/s full duplex lines and their hardware can use the full available bandwidth, even thanks to software optimization, load balancing and widespread WireGuard usage. To reflect project completion we have modified the real time servers monitor accordingly. https://airvpn.org/status The displayed throughput is again the sum of the total throughput (up+down bandwidth) as usual, but the total available bandwidth is the total up+down bandwidth which the server is, from now on, really capable to use. As usual, if you need a more detailed overview, including stats, history and distinction of up and down bandwidth, you can click the server name. Kind regards & datalove AirVPN Staff

@SurprisedItWorks Hello! Resolved, please see also https://airvpn.org/forums/topic/56492-congested-canadian-servers/?do=findComment&comment=224442 Kind regards

Hello! The migration to 1 Gbit/s full duplex lines is complete. Now all servers are on 1 or 10 Gbit/s lines full duplex AND the new hardware is not a bottleneck. We have updated the real time servers monitor accordingly. Expansion plans in Canada are approved, stay tuned. Behind the scenes a lot of work is ongoing and you can see the outcome now: in various areas the available bandwidth has been physically doubled. More to come in the near future. Please consider that recently a couple of VPN competitors went bankrupt, another one was bought by a big shady group (causing widespread customers' migration), and a couple of other relevant VPN services suddenly canceled an essential service that we routinely offer, pushing a massive amount of customers to leave. All such events occurred in a very short time span, so distinct migration waves overlapped. Nothing that we can't handle anyway, because the infrastructure was oversized. Please follow the "News" forum for updates and announcements. Thank you all for your choice! Kind regards