Jump to content
Not connected, Your IP: 3.135.246.193

Staff

Staff
  • Content Count

    10614
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1766

Everything posted by Staff

  1. 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
  2. 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
  3. Hello! Quick preliminary check, just in case: https://airvpn.org/forums/topic/56912-black-friday-ad-stops-connection/?do=findComment&comment=227088 Kind regards
  4. 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
  5. @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
  6. 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
  7. 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
  8. Hello! We're sorry, the new servers will not keep the same IP addresses. Kind regards
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. @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
  24. 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
  25. 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
×
×
  • Create New...