Staff

Hello! Can you please open a ticket? We need to investigate this issue more thoroughly as we detected an apparent anomaly after a ticket by a different user with identical route outside problem even when the IP addresses were correctly entered. NOTE: if you are the same person and you opened a ticket from a different account, can you please reply to the support team? They are waiting for an important information from you since days ago and they have not received any reply. You need to re-start the VPN connection. Kind regards

Hello! Yes, stay tuned! Kind regards

Hello! For the readers, the problem has been explained, simply AROU666 does not have and has never had access to the VPN servers. 😲🤨 The community forums are open to everyone, not only to users with a valid VPN access plan. Kind regards

Hello! All servers except Metallah (Pennsylvania, USA) support IPv6. IPv6 malfunctions in datacenters are more frequent than IPv4 malfunctions, but our server monitor will detect them and a server with IPv6 problems will become "yellow" (ongoing problems) or "red" (inaccessible). Kind regards

Hello! Please keep using WireGuard and modify the MTU size through the "MTU = n" directive, where n is in bytes. For each size re-start the connection and test the performance thoroughly. Consider at least a couple of VPN servers located around your node and maintain them to cross-test consistently. To modify the MTU size please edit (with any text editor) WireGuard's configuration file and add a line in the [Interface] section. Start with: MTU = 1280 then go up at 20 bytes steps (1300, 1320, 1340, ..., 1420). Do not exceed 1420 at the moment. If you see a performance improvement, keep going up. When you see a performance degradation, fine tune between the last and the current value. If you see poor performance regardless of the MTU size, consider to switch to OpenVPN in TCP mode, in case UDP is capped in your network. Kind regards

Hello! It is probably impossible for the community to give you a problem solving suggestion with the current information and maybe someone will ask you for more info, such as your system name and version, the log of the program you run to connect to the VPN and so on. Please feel free to open a ticket in the meantime (by clicking "Contact us" on the web site or by writing to support@airvpn.org) to receive assistance directly from the "AirVPN Support Team". Kind regards

Hello! Relevant vulnerabilities affect OpenVPN from 2.6.0 to 2.6.6, from 2.5.0 to 2.5.2, and 2.5.6 (as well as multiple openvpn-connect versions, not relevant here), but not 2.5.5. https://www.cvedetails.com/vulnerability-list/vendor_id-3278/Openvpn.html Do you have any breaking news on OpenVPN 2.5.5? Kind regards

Hello! We see two different problems. Please see here for an explanation and a quick solution of the first problem: https://airvpn.org/forums/topic/56657-cant-connect-to-anything/?do=findComment&comment=225418 The second problem seems related to IPv6. Maybe your ISP does not support it, or the first problem is causing the second one too. If the solution to the first problem does not solve the second one, please go back to the default setting. You have forced Eddie to connect over IPv6 in "Preferences" > "Networking" window. Switch the "Protocol used for connection" combo box back to "IPv4, IPv6" (currently you have set it to "IPv6, IPv4"). Kind regards

@Koalaman Hello! Even better now. And yes, 396 Mbit/s in download is expected from New Zealand servers (consider that on the server 2x bandwidth is needed). It's anyway a good performance in general in our infrastructure. The upload speed is very close to max capacity (40 Mbit/s) so it's perfect now. Kind regards

Hello! With connection timeout (error 110) the port tester did not receive any reply. With connection refused (error 111) the connection was reset (packet "actively rejected") by your node (with error 111 you know for sure that the packet reached your client). In both cases you must make sure that the docker is configured to accept unsolicited packets on the proper ports and that the respective listening programs are really running and listening to the correct ports. Furthermore, no packet filtering tool must block incoming packets. Support team is available if you need official support. In this case, if you decide to open a ticket, it may be useful that you include the docker-compose file and the list of the programs which should receive (and reply to) the incoming packets. Kind regards

Hello! Let's check directly from inside a VPN server where you experience the problem so we can definitely see whether there's some problem in the server itself. Please open a ticket to arrange the tests at your convenience. Please note that we can reach regularly your Plex server on the current VPN server (not in Canada) you're connected to. Re-direction to Plex services (app.plex.tv) then occurs for login purposes, and this is exactly what we suspected, i.e. it's possible that some AirVPN servers are blocked by this in-the-middle service, while others are not. Is it possible to reach a home Plex server without any interference by or re-direction to Plex owned infrastructure? Kind regards

Hello! All server port forwarding works identically and no anomalies have been detected in specific investigations brought on manually during these very days for "false alerts". You can safely assume that port forwarding is working perfectly and identically on all servers. The problem might have a different cause. Do you use some in-the-middle Plex server (i.e. machines operated by Plex company for example aimed at Plex Pass, Plex Streaming, Plex Cloud) to access anything? Kind regards

Hello! All problems were resolved. For the readers: YuNoGuy problem was caused by the Windows Firewall blocking the incoming traffic of other programs his/her main listening program relied on. Check the message here for interesting and useful details: https://airvpn.org/forums/topic/56970-port-forwarding-connection-timeout-error-110/?do=findComment&comment=227771 JebediahWolfe (original poster) problem was caused by the fact that the remotely forwarded port was disabled by the user in the control panel. All ports are enabled by default when you reserve them to your account and a new option allows you to disable them without de-allocating them. It is an option which can be useful under specific circumstances and required by some users. Always pay attention when you change settings. Voja Ten. problem "disappeared by itself" from one day to another so we can't say anything about it. Kind regards

@AROU666 Hello, please see our previous message and open a ticket. Since your account doesn't have access to AirVPN the whole discussion has been pointless, we're sorry. Kind regards

@AROU666 Hello! 1. Please disable UPnP too. 2. Port 50632 is not assigned to your account. Please configure SoulSeek to listen to the correct port. Assuming no "re-mapping" for simplicity's sake, the remote port number and the local port number must match. 3. Your account does not have access to AirVPN servers, please check your account status. Kind regards

Hello! Since OpenVPN works, it is plausible that your ISP blocks WireGuard. If that's the case you must keep using OpenVPN only (or change ISP of course). You might like to get informed about the block / traffic management policy enforced by your ISP. To investigate on the Android side, please open a ticket at your convenience. Kind regards

@AROU666 Hello! First and foremost please check the post set as best answer in this thread, the mentioned setting modification resolved the problem in other cases. In your specific case, you have an apparent double mis-configuration, as you keep even UPnP enabled, on top of NAT-PMP. Kind regards

Hello! Yes, definitely. Stay tuned and follow the "News" AirVPN forum for updates. 😉 Kind regards

@JebediahWolfe Hello! Once again we invite you to open a ticket. Other users in this thread have all resolved their problems when they did so. Kind regards

@absolution Hello! New pieces of information from another thread:Kind regards

@Aeto Hello! We're sorry, we do not offer SOCKS5 proxies. Please see also/again (thanks @ace0o0o ) https://github.com/qdm12/gluetun/issues/1523#issuecomment-1674569764 Kind regards

@BettyIsBoop Hello! We're going to look into the issue. Since you get SERVFAIL, the mappy.fr authoritative DNS might be down or more probably it's blocking some or all of our VPN servers. Can you also tell us which VPN server(s) you experience this problem on? Kind regards

@dshbfjdsaauj Hello! Something is not working properly, can we see Eddie's system report generated while the system is connected to the VPN? https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Kind regards

Hello! Try to see how Gluetun can know and reach your local DNS. Also check the following thread: https://airvpn.org/forums/topic/56915-very-rarely-getting-rogue-dns-servers-when-checking-for-dns-leaks/?tab=comments#comment-227164 You might also like to contact Gluetun community and support. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s full duplex server located in Chicago, IL (USA) is available: Praecipua. The AirVPN client will show automatically the new server. If you use any other OpenVPN or WireGuard client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts OpenVPN connections on ports 53, 80, 443, 1194, 2018 UDP and TCP, and WireGuard connections on ports 1637, 47107 and 51820. Just like every other Air server, Praecipua supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, tls-crypt and WireGuard. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the server status as usual in our real time servers monitor: https://airvpn.org/servers/Praecipua Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team