Staff

@2mD Hello! UDP seems blocked: You need to search for any possible filter against UDP or more generic filter. Assuming that the ISP is the same, the block could be self-inflicted. As you changed only the router, first check the various Speedport Pro filters. This router offers a very wide variety of filters, including filters on protocols and destination ports. Kind regards

Hello! The previous problem is resolved. When the connection attempt fails your network is unreachable according to OpenVPN: . 2024.07.01 15:57:48 - OpenVPN > write UDP: Network is unreachable (code=51) . 2024.07.01 15:57:48 - OpenVPN > Network unreachable, restarting The error message hints at various options: your network is down your physical interface is down the network is up but UDP is blocked directly in the machine (check firewall etc.) Please test a connection over WireGuard to see whether WireGuard can't reach the network too. Switch to WireGuard in Preferences > Protocols window (uncheck Automatic, select any WireGuard line and click Save). Kind regards

Hello! Most servers, but not all, in the Toronto datacenter suffer of a 20-30% persistent packet loss on IPv6, therefore the system sets them in "yellow" status with the "Low packet loss" message. If you don't need IPv6 you can anyway force a connection to them as IPv4 works just fine. We are being assisted by the datacenter technicians to understand the cause of the problem. Kind regards

@gamuza Hello! You have forced Eddie to connect using IPv6, but either your network, router or ISP doesn't support IPv6. Please switch back to IPv4: in the Preferences > Networking window, change the Internet Protocol used for connection combo box to "IPv4, IPv6" (the default setting), click Save and test connections again. If your system supports IPv6, our VPN servers will allow you to use IPv6 over IPv4 even if your router and/or ISP do not support IPv6. Kind regards

Hello! We're sorry to inform you that Altais (Kiev, Ukraine) has been canceled by the service provider due to our refusal to provide 100% warranty that non-permitted activities will ever take place on the server, which is of course an impossible commitment not only for VPN but for any ISP providing private citizens with any online service in general. We're also sorry to inform you that we have no plans at the moment to rent new servers in Kiev or anywhere else in Ukraine because of various factors, among which the behavior of local police (remember in the past the request for bribes masked as fines to unlock servers) and the unreliability of local datacenter managers, which seem to be used to cancel services without notification and without refunds. Over the past decade, the behavior of Ukrainian datacenters and local authorities has brought nothing but inconvenience to our customers, so it is time to (at least temporarily) suspend operations there. Kind regards AirVPN Staff

Hello! Can you please send us a system report generated by Eddie after a connection attempt has failed? Please see here: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Kind regards

@Shotmaker Hello! The route check must necessarily take place after the connection has been already established successfully, because it is a check to make sure that the traffic goes through the VPN tunnel. Your traffic did not leak and you have no reason to worry. You are protected against traffic leaks both by Network Lock and by the network interface binding you describe. No leaks can occur. You have the impression that torrents did not stop immediately after a VPN disconnection just because the counters have a progressive modification in qBittorrent (as well as in many other torrent clients). Kind regards

Hello! We're sorry, AirVPN DDNS does not support SRV records. You may find SRV supported in third party DDNS, such as no-ip with the Pro DNS plan. Kind regards

@gamuza Hello! Can you tell us your Operating System name and version as well as the name and version of the program you run to connect to AirVPN servers? Kind regards

@gxxxx Hello! Please test WireGuard (in place of OpenVPN) and also compare your torrent software settings with the following guide: https://airvpn.org/faq/p2p You can find the instructions to run and configure WireGuard on compatible systems here: https://airvpn.org/download or you can run one of our native programs supporting WIreGuard, if available for your system. Kind regards

@Greyzy Malwarebytes' behavior has been unspeakable for years, and it seems even worse now that they are trying to promote their VPN. We're very glad that you resolved the problem. If only you had mentioned Malwarebytes earlier we would have immediately identified the problem because Malwarebytes has been infamous for blocking VPNs and other services for no reason for over a decade now. In this case it does not block VPN protocols, but it poisons even the innocuous resolution of domain names bypassing both your hosts and DNS settings. Imagine which degree of control over your machine you have given to Malwarebytes, up to the point to cause malfunctions requiring intensive work to be resolved. https://airvpn.org/forums/topic/59721-malwarebytes-blocking-airvpn/?do=findComment&comment=233910 Be more careful when you let other software control your system against your will next time. Kind regards

Hello! Just to avoid potential confusion, the limit is 5 ports per account. Only accounts registered with the earlier contractual agreements can still enjoy 20 ports, i.e. the change enforced on June 2023 is not retro-active: https://airvpn.org/forums/topic/56405-port-forwarding-availability-change/ We are finalizing a deep infrastructure change, started more than 6 months ago, which will avoid port exhaustion for many years (we guess for the whole company lifetime) and which will allow us to offer more inbound forwarded ports per account (if needed) at a fair price. The change will not rely on "regional" or "server group" ports, so the comfort of the current system will remain. Kind regards

@Greyzy Hello! According to your screenshots and provided that your description is accurate, Fritz!Box is resolving the same domain name differently for different devices. This is a typical behavior of filters (parental control etc.) applied on a device basis. Different devices querying the Fritz!Box as DNS can have different resolutions. Kind regards

@Greyzy Hello! Just an additional verification: please check filter lists in the Fritz!Box and make sure that AirVPN domain names are not included. Kind regards

@Greyzy Hello! Our regional (country / continent / world) domain names for "best" servers change their records frequently, according to https://airvpn.org/faq/servers_ip/ . That's why you can get a different resolution every 5 minutes. This matter is totally irrelevant for the problem you experience, don't worry about it. It is possible that Vodafone is messing up your DNS queries. We saw this shameful behavior in the past, many years ago, by Vodafone Italia, which re-directed anything to port 53 to force resolution of names by its own DNS servers and also prevent any other protocol to port 53. We can't rule out, according to all the data you provided, that this is the case for you too, with the addition of some acrimony against our VPN domain names. The problem should get resolved by DNS over TLS to port 853. Unfortunately Windows 7, as far as we know, can't support it, but Windows 10 (which runs in another machine of yours) and the router can: please test it. Once the router is configured properly for DNS over TLS, you can configure your Windows 7 system to query only the router for names resolution (in the DNS settings enter only the router address in your local network). Important side note: please consider to drop Windows 7 as it is an abandoned system ever since a long time ago. Kind regards

@Greyzy Hello! The domain name included in the configuration file generated by the Configuration Generator is fully qualified, as you can verify independently. The problem is always the same as you can see even from nslookup: poisoned/wrong resolution (into a non-routable address). The problem is not in domain names or configuration files. Specific example for de3.vpn.airdns.org: note how Quad9 (9.9.9.9) resolves correctly and this adds another strange piece to the puzzle because nslookup said that it queried Quad9 to resolve de3.vpn.airdns.org, but gets an answer that surely does not come from Quad9. This suggests some worrying scenario, but don't let us jump to conclusions too early: just switch to DNS over TLS (supported by Quad9). Configuration needs a little bit of documentation, please check (while you are in the VPN): https://www.elevenforum.com/t/enable-dns-over-tls-dot-in-windows-11.9012/ DNS over TLS will ensure that your DNS queries will not be tampered by your ISP or any MITM (when you are in the VPN you are already protected as the DNS is inside the VPN, but when you're not connected to the VPN you're not protected). $ drill @9.9.9.9 de3.vpn.airdns.org ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 27288 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; de3.vpn.airdns.org. IN A ;; ANSWER SECTION: de3.vpn.airdns.org. 300 IN A 37.120.217.245 ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 151 msec ;; SERVER: 9.9.9.9 ;; WHEN: Wed Jun 26 20:58:14 2024 ;; MSG SIZE rcvd: 52 Also, please answer to the relevant question by @go558a83nk Kind regards

Hello! Same as before we guess, although you did not send new log: name resolution problem. Please re-check DNS settings and test resolution with "nslookup" command. According to the previous recommendations you must set DNS properly on the router too. Kind regards

@kuchito Hello! No, please take note it's 29898. From your description we infer that Jellyfin listens to port 29892 but from the compose file it appears that you forced Gluetun to re-direct packets for port 29898 to port 80. On your AirVPN account port panel you forwarded inbound port 29898 to your local port 29898. Therefore: fix the error in the compose file: packets to port 29898 must be directed to port 29898 (and not 80) fix the error in Jellyfin configuration. It must listen to port 29898 and not 29892 Alternatively (deprecated), do not touch Jellyfin configuration but modify the compose file to re-direct packets for port 29898 to port 29892 (we would not recommend this solution, it's somehow messy). Kind regards

Hello! Hopefully nothing serious has happened and let's hope that their site will be up again soon. Kind regards

Hello! On each PC and on the router. PC DNS settings take precedence, but if a PC queries also the router (even if only as a fallback) then it's essential that the router DNS is not poisoned. So change them all. Please check https://www.opennic.org Kind regards

Hello! Change DNS settings, have your system query only Quad9 and OpenNIC. Kind regards

Hello! Nothing related to *.airdns.org, therefore the problem is not there. However, your hosts file has been edited to prevent license verification by Adobe servers. Kind regards

Hello! Names resolution order in Windows default settings is: hosts file DNS NetBIOS DNS is queried if no match is found on the hosts file. hosts file is typically edited by filter programs to force some domain names to resolve into non routable IP addresses, as it happened in your case with our FQDNs. Just to make two examples, to block resolution of ad related names, or prevent access to dangerous services. Please check your hosts file and also make sure that your machine queries a neutral DNS (we recommend Quad9, 9.9.9.9, for commitment to privacy and neutrality). Kind regards

Hello! The AirVPN Suite is not "close" to official software, it is indeed official software for Linux by AirVPN. It is the only official software by AirVPN capable to run also on Linux distributions not based on systemd. Kind regards

@nighthawk68 Hello! If the VPN connection goes down and up and the virtual network interface is destroyed and re-created, qBittorrent could need a re-start in order to bind to the interface again. Kind regards