Staff

Hello! We're very glad to know that the problem is solved. From the OpenVPN manual: Since mssfix 1280 resolved the problem, a plausible explanation that comes to mind is that before the problem started your network had frames fitting the previous MTU, and this is no more possible now So, it could be a change on your ISP side. Kind regards

Hello! Please note that the ability to connect over a generic HTTP, HTTPS, SOCKS4 and SOCKS5 proxies, especially those only supporting TCP, is an OpenVPN strong feature that's not matched by WireGuard. The flexibility and ease of OpenVPN to do it is very important for anyone connecting from behind a proxy (such a corporate proxy). This is a feature that we do no want to lose so phasing out OpenVPN in its entirety is not on the table at the moment. Another similar, powerful feature that WireGuard can not offer is establishing an SSH tunnel, or a TLS one (by stunnel typically) and then connect OpenVPN over it. However, a balanced approach is possible, and we are already moving toward that direction. For example, our kernel networking tuning is preferring WireGuard needs, not OpenVPN ones, although the approach is not too unbalanced. In the future we might also consider to lower the amount of concurrent OpenVPN processes we run on servers (we do it to aid balancing for the notorious problem you mention and for which a stable and easy to maintain DCO would be a solution). Kind regards

Hello! We have a report that makes us suspect that in Uzbekistan it's the IP addresses of various VPN servers (not only AirVPN, other VPN too), to be blocked "unconditionally". Anyway AmneziaWG is worth a test, with and without QUIC mimicking, toward all the wg ports of our servers. It has an incredibly high rate of success in Russia and China (higher than OpenVPN over SSH and shadowsocks) so it's definitely worth a test. Please keep us posted as we have literally three reports only from Uzbekistan including yours... If you need some parameters to test check here: https://airvpn.org/forums/topic/77633-eddie-android-edition-400-preview-available/?do=findComment&comment=258644 and here: https://airvpn.org/forums/topic/59479-block-vpn-in-russia/?do=findComment&comment=237288 If you need some suggestions for the parameters In in order to mimic QUIC connection to some specific web site known to be not blocked in countries controlled by VPN hostile regimes, please contact our support team in private by opening a ticket. Kind regards

Hello! Please note that the TLS handshake and anything else is performed by and between your system and the final web (or other service) servers. The VPN server is not a part of this process. Of course airvpn.org and ipleak.net do not block AirVPN servers. We would rather suspect some MTU related problem. Try to add in your OpenVPN configuration the following directive: mssfix 1280 Can you also test, in the problematic system, a connection by running OpenVPN directly and not relying on the network-manager-ovpn plugin? In the past it caused several different problems and it was deprecated. If the problem persists please test with ufw completely disabled. Do you mean that the problem doesn't appear at all on different systems using the same OpenVPN connection mode (entry-IP address, port and protocol)? Kind regards

Hello! Yes, as the default settings are not adequate for high load and high throughput servers. Kind regards

Hello! Reading it is not sufficient, then you have to change your configuration accordingly. How did you add the end point (destination VPN server)? Kind regards

@Bobo90 Hello! Your compose file lacks the proper setting of the FIREWALL_VPN_INPUT_PORTS environment variable. If you set it on the command line options fine, but if not you must add it and set it properly. The FIREWALL_VPN_INPUT_PORTS environment variable in Gluetun specifies a comma-separated list of ports that must be allowed through the firewall. Without it, packets forwarded by the VPN server will be dropped by GlueTun firewall. About this error: "ERROR [vpn] finding a VPN server: target IP address not found: in 250 filtered connections". you should be able to resolve it by reading the documentation specific for AirVPN: https://github.com/qdm12/gluetun-wiki/blob/main/setup/providers/airvpn.md Kind regards

Hello, there's at least one Usenet provider that caps traffic of any VPN competitor to boost its own offer. This is an anti-competitive practice. Thank you for not advertising. With that said please open a ticket to investigate, especially if you get poor performance when you access any other service while connected to the VPN. Kind regards

Hello! Can you tell us your OS name and version and which Eddie version you're running? Kind regards

@airvpn12345 Hello! It's not an authorization problem, but WireGuard traffic is blocked. Can you please check any antimalware tool on your system, as well as the Windows Defender firewall, and make sure that they do not interfere with UDP and WireGuard traffic? Please check also your router and disable, if active, any traffic management tool. Kind regards

Hello! Please make sure that Eddie is not configured to connect automatically at startup on "Preferences" > "General" window. If the problem persists and you do not recognize the session(s) it is necessary to keep into consideration a possible unauthorized use of your account. Please change your AirVPN user password (pick a strong password you do not use anywhere else) and renew your keys to cut out any potential fraudulent user, please see here: https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/ Kind regards

Hello! You need to log your account out and in again. When "Remember me" is active, Eddie Desktop edition stores locally all the information. The idea is that when you're in a network that prevents bootstrap servers access, you can count on a reliable local copy to get the vital connection information. In order to force Eddie to update this copy, it is necessary to log the account out and then log it in again (from Eddie's main window). This is not necessary in Eddie Android edition which keeps a local copy but tries anyway to update it whenever possible. Kind regards

Yes that was clear. Now, is there Eddie's tray icon or not in the system tray after you have closed the promotional window? Kind regards

Yes, it's a mix. We could consider to publish this data actually. To be honest an owned server offers negligible security bonus over a leased one, unfortunately. Globally we work with 18 different dacenter owners / providers with servers in 33 different towns (physically, not with address re-location) and with transit served by, or direct peering with, all the "14 giant" tier 1 networks except Telxius/Telephonica and Sparkle, as well as a few important tier 2 providers. In the VPN infrastructure M247 has a 3% presence in America, 36% presence in Europe (but 14% in terms of total available bandwidth), 95% in Asia, 0% in Oceania. Leaseweb has 0% presence anywhere, there's not even a single VPN server from Leaseweb in the VPN infrastructure. Kind regards

Hello! Yes. The kernel already does a wonderful job to distribute fairly bandwidth, aided by the excellent ability to scale of WireGuard. OpenVPN is a little more problematic but we force a round robin distribution of peers on different instances to balance core load. Where a limit must be enforced artificially is in the amount of concurrent connections INSIDE the tunnel. Normally we allow the maximum amount supported by a powerful home router, i.e. 20000 concurrent connections per node. This limit is usually not even noticed by the users as it is well beyond the usage of virtually all of our user base. Kind regards