Staff

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

Hello! The system command netsh, invoked by OpenVPN (a protocol and the program creating the point to point VPN tunnel), fails: Try to switch to WireGuard (another program and protocol to create point to point VPN tunnels) to verify whether the problem is related to the virtual network interface creation process (which is different when WireGuard is used): select from Eddie's man window "Preferences" > "Protocols" uncheck "Automatic" select a line with WireGuard click "Save" and test again a connection and report back whether the connection is successful or not. In both cases, please consider to send us a system report generated by Eddie after the problem has occurred. Please see here to do so: Kind regards

Hello! In the meantime, please check here: https://eddie.website/support/data-path/ Kind regards

Thank you, we updated the original message. Kind regards

Hello! Thanks for the report, could you please duplicate this message of yours in this thread: https://airvpn.org/forums/topic/56428-eddie-desktop-223-beta-released/ During this testing phase, we will try to gather all the previously undiscovered bugs in that thread. Kind regards

Hello! Yes, we bet on a IP geo-location database compiled at the drop of a hat and we have even a hint to understand the incompetence, see below from the official IANA WHOIS server db: $ whois 146.70.94.2 % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object refer: whois.arin.net inetnum: 146.0.0.0 - 146.255.255.255 organisation: Administered by ARIN status: LEGACY whois: whois.arin.net changed: 1993-05 source: IANA # whois.arin.net NetRange: 146.70.0.0 - 146.70.255.255 CIDR: 146.70.0.0/16 [...] # whois.ripe.net inetnum: 146.70.94.0 - 146.70.94.255 netname: M247-Dublin descr: M247 Europe - Dublin Infrastructure geoloc: 53.350140 -6.266155 status: LEGACY remarks: Geofeed found at https://geoip.m247.ro/geofeeds.csv country: IE Kind regards

Hello! Your Deluge program is reachable (just tested) from the Internet, and replies properly. Your setup seems correct. Deluge tests are performed through specific servers which might be unable to reach our servers. Therefore, the performance problem should have a different cause: if it persists on well seeded torrents and regardless of the VPN server you connect to, please feel free to open a ticket. Kind regards

Hello! It is meant to block Spotify ads. Kind regards

Hello! GoodBye Ads has been added after widespread community suggestions and it is here to stay as long as we don't have another widespread request from the community to delete it. Just ignore it and that's it. Please report the problems you have with Eddie Android edition in the proper thread or even better in a ticket. In this thread they are off topic and contribute only to lower thread's readability. Since the "News" forum is not a community forum and it must remain as readable as possible, off topic messages might be split or even deleted in some cases. Kind regards

Not systemd, they wanted to verify whether you had systemd-resolved DNS enabled with old Eddie versions and similar behavior in Android with other tools, because you said that without VPN DNS the sites were not broken and at the same time you wrote (quote): It was you who claimed initially that the problem was NOT related to the DNS block lists, that's why initially the investigation moved to other fields, holy patience! Kind regards

Hello! You bind a program to a network interface, not a virtual network to a program! In order to do so, you can modify the following option: Set it to the virtual network interface (for example wintun in Windows). Also note that by keeping Network Lock enabled you will prevent in any case (including torrent software mis-configuration) any possible traffic leak. Kind regards

Hello! The problems you experience are caused by various Eddie bugs. Please test Eddie 2.23.1, where several bugs have been fixed, including the bug causing the option --mode.type to be ignored or incorrectly parsed. Please see here: https://airvpn.org/forums/topic/56428-eddie-desktop-223-beta-released/ Please feel free to keep us posted after you have tested the new Eddie. Kind regards

No, if all peers were not reachable BitTorrent would not work at all. The reason is trivial, just study how the protocol works. Actually there are many "dead torrents" not because there are no peers with the complete file, but because those peers in the swarm are active but not reachable. You have the impression that torrenting works even if some peers in a swarm are unreachable only because there are peers which are reachable in that swarm, so unreachable nodes (leechers) can keep leeching. This is the essence of the claims "you can keep torrenting even without remote port forwarding": yes, provided that parasites in a swarm can leech thanks to the effort of others. Maybe you should study how the protocol works before insulting. We're momentarily locking this thread, too many off topics are making it confusing. Kind regards