Leaderboard

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! 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

To use DNS over TLS on the Fritz!Box, no additional settings must be done for the LAN adapters on each PC. This option is for outbound DNS queries from the Fritz!Box (e.g., when one device queries the Fritz!Box for some name, Fritz!Box forwards this to the DNS over TLS server itself).

Lots of slow, maxed out servers, lots with high packet loss. What is going on?

@Mytob do you use the wireguard protocol or the OpenVPN ? So let's say your qBt server IP is 10.0.12.9, the port you want to forward is 4321 and the interface of the Wireguard client that you created is the wgclt3 1) You have to forward the port with a rule in the chain PREROUTING of the table nat: iptables -t nat -I PREROUTING -i wgclt3 -p tcp --dport 4321 -j DNAT --to-destination 10.0.12.9 iptables -t nat -I PREROUTING -i wgclt3 -p udp --dport 4321 -j DNAT --to-destination 10.0.12.9 With WG I noticed that I had to add a rule in the forward chain to let the packets go through. (I don't know why, maybe it is the same with the OpenVPN because of something changed in the recent releases of the unifi OS). 2) So you add the following rule: iptables -I FORWARD -i wgclt3 -p tcp --dport 4321 -d 10.0.12.9 -j ACCEPT iptables -I FORWARD -i wgclt3 -p udp --dport 4321 -d 10.0.12.9 -j ACCEPT Rmq: a) I use INSERT to add my rules so I'm sure it's it placed at the top of the chains and proceed before everything elese. b) I also noticed UDP packets coming from the airvpn server. It comes from the port used to connect on it (1637) and those are DROP by the firewall. The host's resolution changes from time to time. So I'm not sure how to deal with this problem. I'm considering opening a ticket to verify if this is a normal behavior, as I wonder why I get such UDP requests. I could add a rule like: iptables -I INPUT -i eth8 -p udp --sport 1637 -j ACCEPT But it's too permissive. 🤔

This is what I do: https://github.com/tool-maker/VPN_just_for_torrents/wiki/Running-OpenVPN-on-Windows-without-VPN-as-Default-Gateway Works for Wireguard too. You add routing table entries to put the original default gateway back in effect (using a provided script - copy and paste). Basically you have all public IP addresses routed outside the VPN. And then bind the torrent client to the VPN interface (or address) to have it use the VPN. In Windows, a program bound to the VPN interface will ignore routing table entries that are not for the VPN interface. So it sees the VPN as the only route. I have used this (I wrote the scripts there) for many years. Some people complain that this is too much reading/too technical/too much work. But you really just have to copy and paste a couple of .bat scripts for the routing. Also, a caveat. This really does rely on the torrent program binding properly to the VPN interface. From that page: "If you are using uTorrent, uTorrent (older releases at least) will ignore your instruction to bind the VPN and use the default gateway if the address you specify does not exist." Recent versions of qBittorrent seem to have become unreliable for this too. I use Transmission (transmission-daemon.exe). For safety, I use Windows firewall to block the torrent program from using the real interface. The method is to block out-going traffic for that program from IP ranges 192.168.0.0/16 (for IPv4) and 2000::/3 (for IPv6). This presumes that your router uses NAT for IPv4 (with the usual LAN private address range) but not for IPv6. You can start Windows Firewall by executing "wf.msc". Or find it in the start menu. Add the rules in "Outbound Rules". One for IPv4 and one for IPv6. The address goes in the "Scope" tab in "Local IP address". Check "Block the connection" in the "General" tab. The program path goes in the "Programs and Services" tab in "This program".

Already possible for quite some time. Make sure to tick the "Advanced Mode" checkbox, select the countries you wish, and add "remote-random" in the "Custom directives:" section.