wireguard Torrent tracker timeouts

[sinan1568 0]

I just purchased an AirVPN plan and set up the WireGuard connection to replace a Mullvad one. The connection operates in a separate namespace (just like the Mullvad one before it). I have port forwarding enabled, and when testing the port on my AirVPN profile page, it says the port is open. However, my rtorrent client seems unable to connect to any of the trackers. Tracepath shows timeouts to some sites, but e.g. grabbing a kernel tarball works just fine.

Setup, route and MTU seem okay to me.
 

# ip netns exec wireguard wg show
interface: wg0
  public key: <snip>
  private key: (hidden)
  listening port: 51727

peer: <snip>
  preshared key: (hidden)
  endpoint: <snip>
  allowed ips: 0.0.0.0/0, ::/0
  latest handshake: 1 minute, 20 seconds ago
  transfer: 142.67 MiB received, 7.39 MiB sent
  persistent keepalive: every 15 seconds

# ip -n wireguard route
default dev wg0 scope link 

# ip -n wireguard a s
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1320 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.xxx.xxx.xxx/32 scope global wg0
       valid_lft forever preferred_lft forever

A tracepath for e.g. Redacted's tracker will show just fine but rtorrent shows only tracker timeouts; it doesn't even seem to try to update the tracker when I tell it to do so manually. Hop times are high though (routing through Canada from Europe).
 

# ip netns exec wireguard tracepath flacsfor.me
 1?: [LOCALHOST]                      pmtu 1320
 1:  10.128.0.1                                          108.463ms 
 1:  10.128.0.1                                          108.575ms 
 2:  184.75.221.169                                      108.081ms 
 3:  te0-0-1-19.222.ccr31.yyz02.atlas.cogentco.com       108.469ms 
 4:  be3260.ccr22.ymq01.atlas.cogentco.com               116.587ms 
 5:  be2976.ccr21.ymq01.atlas.cogentco.com               115.585ms asymm  4 
 6:  be2182.ccr41.ams03.atlas.cogentco.com               195.332ms 
 7:  be2182.ccr41.ams03.atlas.cogentco.com               195.868ms asymm  6 
 8:  be3433.rcr21.ams06.atlas.cogentco.com               195.476ms asymm  7 
 9:  worldstream.demarc.cogentco.com                     196.031ms asymm  8 
10:  185.165.241.225                                     197.348ms reached
     Resume: pmtu 1320 hops 10 back 10

Kernel tarball pulls in fine e.g.:
 

# ip netns exec wireguard wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.4.7.tar.xz
--2023-07-29 10:42:50--  https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.4.7.tar.xz
Resolving cdn.kernel.org (cdn.kernel.org)... 151.101.125.176, 2a04:4e42:1e::432
Connecting to cdn.kernel.org (cdn.kernel.org)|151.101.125.176|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 137795084 (131M) [application/x-xz]
Saving to: 'linux-6.4.7.tar.xz'

linux-6.4.7.tar.xz                            4%[==>                                                                                       ]   5.37M   186KB/s    eta 4m 53s

Firewall is pretty basic:
 

# Firewall for WireGuard namespace

*filter

## Policies ##
# Set default policies; for now we just accept output
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT

## Loopback ##
# Accept loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 ! -i lo -j REJECT


## Ping ##
# Allow ping requests
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

## Established connections ##

# Accept all established connections. This should mean we don't need to add ESTABLISHED to most.
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


## Rtorrent port ##
-A INPUT  -p tcp --dport abcde -m state --state NEW -j ACCEPT
-A INPUT  -p udp --dport abcde -m state --state NEW -j ACCEPT

COMMIT

Thanks Edited ... by sinan1568

[sinan1568 0]

Anyone?

I have checked by running rtorrent outside the namespace, trackers respond as expected, torrents download etc. Seeing lots of 'Tracker HTTP failed' messages in the rtorrent log, both for HTTP and HTTPS URLs. To be clear: this worked with the Mullvad setup inside the namespace, and curl and wget work like expected in the namespace, as does DNS:
 

# ip netns exec wireguard nslookup redacted.ch
Server:         10.128.0.1
Address:        10.128.0.1#53

Non-authoritative answer:
Name:   redacted.ch
Address: 185.165.241.224

A tracepath on the tracker (flacsfor.me) outside the namespace gives the same timeouts, so that is not part of the issue.

Edited ... by sinan1568
Test outside namespace

[go558a83nk 352]

I've had issues for years with various VPN providers with some public trackers blocking various VPN servers.  However, I could sometimes find a VPN server that wasn't blocked by the public trackers.

But I've never had problems with private trackers blocking VPN servers.

So, not sure what to say but to try different server locations since if the tracker is blocking the VPN servers they've likely blocked the whole IP range.

[sinan1568 0]

Well I've tried so far:
- Belgium
- Canada
- Sweden
- Switzerland

All of them give me tracker timeouts (four different private trackers). Any countries (or specific servers) you'd recommend I test? From what I know, Canada, Sweden and Switzerland are not actively hunting P2P users (nor is Belgium), so I'm not sure why those ranges would be blacklisted by private trackers.

Edited ... by sinan1568