Staff

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

Hello! It's an Invision feature which could be useful sometimes, so we have not disabled it. It is as reliable as the user agent of your browser, which you can change easily. Actually, if look carefully, you might even find probably impossible combinations, such as Safari on Android and so on. Maybe you use a user agent changer plug-in in your browser which rotates user agents. As a side note to harden login security, you may also consider to enable 2FA. Kind regards

Hello! Very odd that you both have normal download speed on the Netherlands servers and very poor on UK servers. All the VPN servers share the same configuration and the load in UK and NL is highly similar. We would rule out a peering problem, otherwise you would see bad upload speed too on the UK servers. Can you also provide additional information such as your Operating System name and version, how you connect to the servers (WireGuard, OpenVPN UDP, OpenVPN TCP...) and (in private if you prefer so) your ISP? Kind regards

Hello! It's an interesting issue we would like to investigate. Tunnelblick and Eddie by default run different OpenVPN versions built by the Tunnelblick developers and Eddie developers respectively. Eddie may also run Hummingbird, based on OpenVPN3-AirVPN library, which is remarkably faster than OpenVPN 2 on Mac (WireGuard is even faster). Did you configure Eddie to connect over OpenVPN 2, Hummingbird or WireGuard? Kind regards

Hello! It's indeed a dubious solution which we can bet wouldn't work. The other class of servers should monitor and log the traffic to promptly ban users (and report them to police, if strictly necessary under specific circumstances) at each complaint, and keep IP addresses "clean" . This is exactly what your ISP already does, so in this case why should anyone rely on a VPN instead of his/her own ISP or some other VPN service which already logs and monitors traffic? Furthermore, there are indeed black lists aimed at exclusively blocking VPN, Tor and anonymous proxy addresses. Logging and monitoring would not resolve the problem you report at all in all those cases (and they are many) for which a service wants to block VPN and Tor unconditionally, no matter how "clean" an IP address is. Why? With a clear a mission and terms of service we think that the whole service is more transparent and honest, so that anyone can make an informed decision. A real problem would be the opposite, i.e. stating a mission and a contractual agreement and then surreptitiously or not break them. Kind regards

Hello! auchan.fr is an e-commerce web site. The reason usually brought on by e-commerce web sites to justify VPN / Tor / etc. blocking is that frauds are less likely from ISP residential lines. If you ask directly they might provide their own reasons. Kind regards

Hello! Remember that you lose the Network Lock feature in this case. Hummingbird 2.0.0 preview for macOS is almost ready and it will let you run WireGuard through wg userspace tool in macOS with Network Lock, if you need it. Stay tuned on the "News" forum. Kind regards

Hello! We too. Same thing, the linked article is correct. Talking about per app traffic splitting we don't, but maybe the community does. You can also consider virtualization or emulation, for example with UTM which runs well in Apple Silicon (it is a QEMU wrapper). https://mac.getutm.app/ Yes, it will be considered for Eddie Desktop edition. Kind regards

Hello! We mean that the VPN servers do not run any OpenVPN process offering connections to clients without encryption (see also https://airvpn.org/specs ). You're welcome. AirVPN infrastructure is based on OpenVPN and WireGuard and in all of AirVPN software you're free to pick either WireGuard or OpenVPN to connect (or you can run any other program which lets you drive either WireGuard or OpenVPN). Choose the one which can provide you with the best performance. Kind regards

Hello! For the readers, we paste here the reply by the support team. Thank you for having opened a ticket on top of your message in the community forum. Kind regards --- Hello and thank you for your choice! Error 111 means that the packet reached your system and it was "actively rejected", i.e. the connection was reset. That's why the packet sender can claim that the connection was "refused". The two main causes of the problem are: 1) a packet filtering tool rejecting the packets (instead of dropping them with no reply or active reset, which would cause error 110). Please check the firewall running in the same machine where the listening service also runs and make sure that it does not block incoming packets. 2) the OS is configured to reset incoming connections to a non-existing port. A port (an end point ID for processes) does not exist when it is not createdt for some process. In other words, if no program is "listening to the correct port", and the system is configured to reset connections to ports which don't exist, you will get error 111 - Connection refused. Please make sure that the listening program: - is really running - is listening to the correct port of the correct interface - does not bind to the physical network interface (just in case it offers the option to bind to a specific interface) because the packets will reach it through the virtual network interface, and not the physical one - has been launched after the connection to the VPN has been already and successfully established - has the option of UPnP disabled (this option would cause a bind to the physical network interface, if UPnP is supported by the upstream/router) Kind regards AirVPN Support Team

Hello! We do not provide proxy services, but only VPN, we're sorry. Small and quick didactic off topic here: using a proxy for a torrent program is a terrible idea, see here why: https://blog.torproject.org/bittorrent-over-tor-isnt-good-idea/ It's simply too dangerous, don't do it. If you need to tunnel only the torrent traffic you can rely on traffic splitting on an application basis. We offer it natively on our Linux and Android software, while on other systems you can rely on third party software, for example WireSock or TunnlTo in Windows. Alternatively, please consider containers or hard virtualization as a safer and much more robust solution. Last but not least Gluetun for Linux has built-in AirVPN support. Kind regards

Hello! Unfortunately the system functionalities which are necessary to start and connect a VPN app during the device bootstrap were removed (remember that in Android Eddie can't have root access). This happened since Android TV 9, if we're not mistaken. The removal of the user option "Always on VPN" does not allow anymore to connect the system to an OpenVPN or WireGuard based VPN during the bootstrap. Some say (but we have not enough elements to support the claim) that this is a malicious castration of the system aimed at forcing the device to exchange data from the real IP address at least during the bootstrap to aid and abet user's profiling and to enhance marketing strategies of the manufacturer or Google itself. Kind regards

@ms2738 Hello! That's correct. We would expect that OpenVPN with AES on Data Channel would be faster than WireGuard (which relies on CHACHA20-POLY1305 for payload encryption) on Intel Mac, because Intel CPUs support AES-NI while M1/M2 do not, but experimentally we see that WireGuard may beat OpenVPN 2 in any case on an agnostic network. On Mac OpenVPN3-AirVPN is remarkably faster than OpenVPN 2 thanks to our optimizations, but even so OpenVPN3-AirVPN struggles to beat WireGuard performance on any Mac. Please experiment and also consider that tests are on a level playing field only when the network is really neutral. For example, if an ISP shapes UDP, then OpenVPN may easily win by using TCP (while WireGuard can work only in UDP). A major blow to OpenVPN is provided by the VPN server itself, unfortunately. While WireGuard scales perfectly and is indeed "multithreading", each OpenVPN process in our servers runs in a single core of a single thread. Besides, in VPN servers you see the CPU load increasing with a more than linear growth with the amount of connected clients, while with WireGuard the CPU load increases linearly or less than linearly with the requested bandwidth, and only secondarily with the amount of connected clients. In the VPN servers we have the kernel modules for WireGuard, while with OpenVPN enormous amounts of data are continuously copied from/to kernel space to/from userspace. We're sorry, while OpenVPN would allow tunnels without encryption, we do not support the feature. For the purposes of our service, it would be a potentially risky option which might backfire. WireGuard can not even be configured to use no encryption. Kind regards

Hello! Unfortunately that's not an option which can resolve anything, except for a few cases. Apart from the problems due to IPv4 space exhaustion, an IP address is listed as related to a VPN (in general to an anonymization service) in a matter of hours. Additionally, some services (LoL apparently is one of them) refuse connections from IP addresses which are not assigned to ISPs offering residential access. Last but not least, IP addresses are added in black lists even for the slightest dubious occurrence (for example a port scan). As you may have tested too, LoL does not work with any major VPN. In some cases, which of course don't include your bank or any financial service which already knows your identity and your habits and usually block VPN with the idea to mitigate frauds, it's up to you to choose whether using a service is worth privacy waiver. Kind regards

Hello! Socket buffers are essential both for TCP and UDP. In general it is a feature of sockets, in the OS TCP/IP stack in general, not something peculiar to OpenVPN. Buffers are essential in both connection-oriented sockets (TCP, SCTP...) and conectionless sockets (UDP). In general all sockets including raw sockets (those sockets which are used at IP layer) have two buffers, a read (aka receive) buffer and a write (aka send) buffer. A program (except for NIC kernel drivers ) doesn't read/write data from/to the NIC directly, it does it through the kernel's network stack. If sockets had no buffers, reading and writing would become too slow for any userspace application. Kind regards

@snrtd Hello! Thank you, we are going to verify and look into the issue. @Flx HTTP is correct, the flow is encrypted inside HTTP. This solution offers a few advantages in specific networks, mainly corporate, school, college networks, where HTTPS is not accepted if you don't install root certificates (usually aimed at traffic inspection by MITM attacks by the college, corporate, school networks which want to monitor all the traffic content of their employees/students/teachers). In this way your credentials and AirVPN certificates/keys are protected even when your machine is compromised by fake root certificates. The method can also bypass some other blocks against HTTPS. The disadvantage is that if you're in a network which rejects HTTP completely or blocks HTTP with direct IP addresses (instead of names) then the Suite or Eddie fails to contact the bootstrap servers by default (but we offer custom bootstrap servers to be added in the run control file). Kind regards

Hello! OK, we suspect that's irrelevant. What about the connection and the throughput? Kind regards

@weelilbit Hello! Three servers in three different locations around your node should be more than enough. The problem unfortunately persists. Can you please test with Tunnelblick, just to make sure that the problem is not a specific block against Eddie (from some tool like LittleSnitch for example), or in general a specific Eddie related problem? Tunnelblick is a free and open source software for Mac, a wrapper and a GUI to OpenVPN, you can find instructions here: https://airvpn.org/macos/tunnelblick/ Kind regards

Hello! Which Operating System and Eddie version are you running? If it's not 2.23.2, can you please test it too and report back? Please see here to download it: https://airvpn.org/forums/topic/56428-eddie-desktop-223-beta-released/ Kind regards

Hello! Your account does not have a valid subscription so you can't use it to connect to VPN servers. If you experience problems to purchase a plan please open a ticket at your earliest convenience by clicking "Contact us" on the web site or by writing to support@airvpn.org Kind regards

Hello! All the dc SLAs are within 24 hours except for hardware failures, which can vary according to hardware replacement availability. The problems in Los Angeles are being tackled and you will see relevant news in a few weeks. We will also take care of Phoenix area if necessary. In general the North American infrastructure has grown remarkably in the last weeks and months. For example, 10 Gbit/s servers have been added in Toronto, New York City, Los Angeles and Denver (this last one with 3 Gbit/s guaranteed). As usual infrastructure modifications will closely follow bandwidth demand and amount of users in specific areas. Kind regards

Hello! Thank you very much. Sabik, Merope and Alkes IP addresses are already located in Los Angeles, in the IANA / ARIN databases, so any geo-location database which reports otherwise is poorly maintained. However, we have decided (breaking news 🙂 ) that those servers will be withdrawn in early 2024 and replaced by more powerful hardware in the LA area (please follow the "News" forum in the next weeks). Kind regards

Hello! The server features a 10 Gbit/s NIC connected to a 10 Gbit/s port. 3 Gbit/s (full duplex) are guaranteed and unmetered. Fully burstable to 10 Gbit/s best effort, 3 Gbit/s (full duplex) commitment 100% guaranteed. Kind regards

@88incher Hello and thank you! Yes, we recommend a prompt update of OpenSSH, of course. If you need OpenVPN over SSH to our servers, we assure you that updates are performed frequently so the update will be applied soon, when it is available in the official repository. Remember that the update must be applied even client side. Anyway, remember that the OpenVPN client, at a first analysis, can't be fooled by this method: if you have connected via SSH, by running a vulnerable SSH client and library, to some entity in the middle which pretends to be us by exploiting the vulnerability, that entity will fail to mimic an OpenVPN connection to one of our servers, because it lacks the proper certificates and keys. On the client side you will be able to establish an SSH connection to the attacker machine (provided that you run a vulnerable ssh), but then OpenVPN will fail to connect. Kind regards

Hello! This is exactly what we do, if you read the mission page you can see it, including the organizations we support through 1) active infrastructural management, 2) monetary support and 3) logistic support with free access. We also support services which are technical, essential platforms for media outlets or single individuals to exercise freedom of expression. Freedom of speech is explicitly mentioned in the mission as we already wrote with the citation in our previous message. Kind regards