OpenWRT Killing P2P Traffic?

I have spent days fighting this issue. I don't know for how long, it might have been ever since I set up a new router and got network attached storage going. I have blamed the hardware, I have blamed the file formatting on the drives, I have blamed the VPN, but having exhausted troubleshooting steps on all of those... has it been OpenWRT this entire time?

Please see

I get 5 minutes of good speeds, but then 15 minutes of crickets, and then it tries again.

See I thought it was because my VPN was on the wrong server, as the company has some specifically configured to support P2P connections. I have tried a dozen of them now. I am not using the wrong servers. I have also set up port forwarding with the VPN and the P2P application, with no change in behavior.

Is OpenWRT triggering some kind of DDoS protection? Where can I go to disable that to allow for P2P connections? I found old topics on SQM, but A) I'm not sure that is relevant to my problem and B) I couldn't find it in LuCi.

Any advice on modifying firewall or something would be appreciated.

Have you tried a non-OpenWrt based router (even your existing one with the vendor firmware) to prove that OpenWrt is the issue here?

We can review your config to ensure that there aren't any obvious errors...

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall

I'll experiment with some linux OS downloads here on two routers. My first foray into OpenWRT worked in my experience, with getting a multi gig .iso within 20ish minutes. Not as great as direct downloads, but it didn't cut itself off after 5 minutes. If that works I'll follow up with that router's config to compare the two.

Output for the poor p2p router:

BusyBox v1.36.1 (2023-11-14 13:38:11 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 23.05.2, r23630-842932a63d
 -----------------------------------------------------
root@OpenWrt:~# ubus call system board
{
	"kernel": "5.15.137",
	"hostname": "OpenWrt",
	"system": "ARMv8 Processor rev 4",
	"model": "Dynalink DL-WRX36",
	"board_name": "dynalink,dl-wrx36",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05.2",
		"revision": "r23630-842932a63d",
		"target": "ipq807x/generic",
		"description": "OpenWrt 23.05.2 r23630-842932a63d"
	}
}
root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd8f:xxxx:xxxx::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'
	option peerdns '0'
	list dns '9.9.9.9'
	list dns '149.112.112.112'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'
	option peerdns '0'
	list dns '2620:fe::fe'
	list dns '2620:fe::9'

config rule6
	option priority '1'
	option action 'blackhole'
	option out 'wan'
	option dest '::/0'

config interface 'vpnclient'
	option proto 'none'
	option device 'ovpnc0'
	list dns '9.9.9.9'
	list dns '149.112.112.112'

config interface 'vpnStream'
	option proto 'none'
	option device 'ovpnc1'
	list dns '9.9.9.9'
	list dns '149.112.112.112'

config interface 'vpnTorrent'
	option proto 'none'
	option device 'ovpnc2'
	list dns '9.9.9.9'
	list dns '149.112.112.112'
root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/soc/c000000.wifi'
	option channel '44'
	option band '5g'
	option htmode 'HE80'
	option country 'US'
	option cell_density '0'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'Dynalink'
	option encryption 'psk2'
	option key 'password'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/soc/c000000.wifi+1'
	option channel '1'
	option band '2g'
	option htmode 'HE20'
	option country 'US'
	option cell_density '0'
	option disabled '1'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'Dynalink2'
	option encryption 'psk2'
	option key 'password'
	option disabled '1'

root@OpenWrt:~# cat /etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option cachesize '1000'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option localservice '1'
	option ednspacket_max '1232'
	list server '9.9.9.9'
	list server '149.112.112.112'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	option ra_slaac '1'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

config host
	option name 'mypc'
	option ip '192.168.1.101'
	option mac 'redacted'
	option leasetime 'infinite'
	option duid 'redacted'

config host
	option name 'mycell'
	option mac 'redacted'
	option leasetime 'infinite'
	option ip '192.168.1.102'

config host
	option name 'raspberrypi'
	option mac 'wireless ethernet'
	option ip '192.168.1.103'  #of note, this hasn't been working to capture the ethernet anymore
	option leasetime 'infinite'

config host
	option name 'laptop'
	option mac 'redacted'
	option ip '192.168.1.104'
	option leasetime 'infinite'

root@OpenWrt:~# cat /etc/config/firewall

config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list device 'ovpnc0'
	list device 'ovpnc1'
	list device 'ovpnc2'
	list network 'wan'
	list network 'wan6'
	list network 'vpnclient'
	list network 'vpnStream'
	list network 'vpnTorrent'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config include 'pbr'
	option fw4_compatible '1'
	option type 'script'
	option path '/usr/share/pbr/pbr.firewall.include'

root@OpenWrt:~# 

Update: After a few hours experimenting. I blame qbittorrent in the end. Libtorrent does some stuff about reputation, yadda yadda. I guess I got to the point where I couldn't find enough people to upload to to keep my ratio at a good level or something, I don't know, that the software just cut me off.

So on a separate PC, I ran a few tests on the current 6 images available to download on ubuntu (https://ubuntu.com/download/alternative-downloads). Downloaded them concurrently.

The first few tests failed. And I figured out that because this separate PC had not torrented in a while, maybe it also had a bad reputation. Or because I purged all the torrents out of it. I don't know. It was going at a snail's pace for an hour. Didn't drop though! Just really slow, and I noticed I had just one peer out of something that should have thousands.

So I purged qbittorrent, deleted all remaining files, reinstalled, and tried again.

My first test was naked. Straight through the ISP. No VPN.

I got some good speeds, up to 8 MBps (or 64 Mbps) and completed all 6 downloads in about an hour. I napped on that part, oops.

I then deleted all the files, deleted the torrents, connected to a VPN, and ran the test again. Just 1 peer... So, I purged qbittorrent again, deleted remnants, and reinstalled. Ran that test, and it worked with decent speeds up to 5 MBps.

Rinse and repeat for the old OpenWRT I had. Speeds of 2-2.1 MBps for peak.

Then I ran the new OpenWRT (just picking up where the old one left off; I didn't purge the files). This got to speeds peaking above 3.0 Mbps a coupel times, but definitely running higher than average compared to the previous router.

I had the issues where qbittorrent would throttle so harshly and reject most connections. But it didn't come with the bolus up front for 5 minutes of good activity like I had been experiencing. I'm hoping once I reset that client and pick out all the directories again for the torrents it will work nicely once more.

However, something I am noticing in the system logs of the impaired connection OpenWRT is a lot of VPN packets being ignored as repeats or something. At one point when I looked, the entire page was just that, for a few minutes worth. Thought maybe that's part of why I had some stalling on downloads, if a packet was recognized as a repeat but the client never actually got it. Oh well, that's speculation, could be related, could not be, but I believe a full qbittorrent reinstall will alleviate some problems.

you could always give transmission a go.

MTU problem with the VPN?

Try lowering LINK-MTU

I may revisit Transmission; that gave me problems before with it not using the vpn, but it was before the time of openwrt holding it.

I will check in on the LINK-MTU suggestion.

This is my latest experiment in data:

It can get the speed, but again it interrupts itself after this is closer to 8 minutes until all activity comes to a crawl. Some of that down speed was probably because I was writing the ISOs to local USB device attached on the laptop doing the downloading; next test will be to try having it write to the NAS drive on the USB port of the OpenWRT router. Most upload activity had been for the content already downloaded to the drive. Which is hard to experiment with, but it should be symmetrical upload/download, and in fact the speed test prior to this batch had 20 Mbps down and 30 Mbps up. It depends of course on the other parties' download speeds, but I feel like I should be getting some more out of this.

Other things to experiment with are restart the OpenWRT router, try to get a cleaner start for it to read and write to the NAS.

Kind of related in my analyzing anything I can - what is Load in the real time graphs? Prior to a lot of troubleshooting, I would see load of "3" unitless. Sometimes I catch it as high as "7" unitless. Not sure what the units are, what the max is, and trying to associate it with CPU levels isn't getting much as I can manually sum up the table of Processes at 10-60% whenever I check it. It's not maxed out that I've ever seen. RAM can get high, but it still shows plenty available, which is fine because I don't think it releases RAM until something wants to overwrite it anyway.

Circling back on the MTU idea: The config provided value was tun-mtu 1500. I can try taking it down to 1440 or 1400, any reason to start with any other value? I don't see a "link-mtu" at a glance, is it synonymous? Also, I did notice maybe I have a TCP v UDP conflict? The OVPN config for my torrent interface is on UDP. I'll also try getting a config set up for TCP and tying qbittorrent to using just one or the other to match instead of having it mix between both udp and tcp.