This is about large files not completing their download.

We are an isp delivering wireless and fiber optic internet service. Some of our subscribers have complained that large files are stalling during their download and won't finish the download. We have looked at MTU, ports, firewall, nat/double-nat, and mangle rules, but don't have a firm bead on the actual root cause.

The subscribers are using a Mikrotik hAPax2 connected to an FTC11 back to a CRS328-4C-20S-4S+ fiber switch, which is connected to an RB5009 edge router that interfaces with our upstream provider on a 1Gig DIA circuit. All the firewall rules are on the edge router. There is NAT at the edge router, and at the home router. We are using unique VLANs for each subscriber with a /30 dhcp network for each VLAN, all networking is on the edge router with a DHCP client on the home router.

Some of the subscribers are using a 3rd party home wifi system such as Orbi or Eero. They have this issue, and so do people without the 3rd party gear. It seems to make no difference what gear is being used, except that when one of our subscribers used a TP link to augment their home network, and now his downloads of larger files work just fine.

Does this issue sound familiar to anyone out there who could take a crack at this?

Yeah — this pattern (small stuff works, large downloads stall/hang, different CPE brands mostly don’t matter, and one TP-Link “magically fixes it”) is classic Path-MTU / TCP MSS blackhole behavior.

In plain terms: somewhere between the customer and the internet, packets bigger than the real path MTU are getting dropped, and the mechanisms that should correct it (ICMP “Fragmentation needed” / PTB, or MSS clamping) aren’t working consistently. A lot of TP-Link gear clamps MSS by default, which “fixes” PMTU problems without you realizing it.

Have you tried something like the rule below?

/ip firewall mangle
add chain=forward protocol=tcp tcp-flags=syn action=change-mss new-mss=clamp-to-pmtu comment="Clamp TCP MSS to PMTU (customers)"

Large file downloads are long-lived TCP flows that eventually try to use larger segments/windowing and hit the path MTU issue.

When PMTUD works, the sender learns “oh, I must use smaller packets” and the transfer continues.

When PMTUD is broken (often because ICMP type 3 code 4 is blocked or rate-limited somewhere), the flow can degrade into retransmits until it stalls.

A different home router that clamps MSS (TP-Link often does) can make the problem disappear.

MTU, MSS and PMTUD issues - PacketLife’s Path MTU Discovery blog post, (not so very) short but very good video TCP MSS clamping – what is it and why do we need it? by Ivan Pepelnjak, 2008 version of Never-Ending Story of IP Fragmentation article from wayback machine, 2019 version The never-ending story of IP fragmentation on ipSpace.net, MTU and TCP MSS when using PPPoE by Samuel Kadolph. Here's another article about PPPoE and DSL How can I optimize PPPoE connections? If you have time and tenacity, read Cisco's Resolve IPv4 Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPsec for a more thorough discussion of the issues.