Copyright and torrent notices

Upstream providers sometimes forward copyright-infringement (DMCA-style) notices saying someone on your network downloaded copyrighted material over BitTorrent. Notices can arrive even when you already block torrents. This playbook covers checking your blocking, tracing the customer, and handling repeat offenders on a MikroTik network with PPPoE and hotspot customers.

1. Check whether your blocking is actually working

Don’t assume a rule is broken because a notice arrived. Look at the live counters on your torrent rules: the Bytes / Packets columns in WinBox, or:

/ip firewall filter print stats

Counters that are non-zero and growing mean the rules are catching real traffic. A typical rule set has:

a Layer7 protocol match for the BitTorrent handshake and tracker requests;
a mangle rule that marks matched connections (for example connection-mark=torrent_conn);
filter rules that drop marked connections and the standard ports (TCP/UDP 6881–6889, 6969, 51413) and DHT bootstrap (UDP 4444).

If the counters stay at zero, check FastTrack first. Fasttracked connections skip filter and mangle rules entirely.

2. Understand the encryption gap

If the rules are working and a notice still arrived, the usual reason is encrypted torrent traffic. Modern clients (qBittorrent, Deluge and others) turn on protocol encryption by default, specifically to defeat port and signature blocking. Encrypted traffic on random ports passes through standard rules.

That’s a limitation of firewall-based blocking on any platform, not a sign of misconfiguration. Blocking every non-whitelisted outbound UDP or high port would stop most of it, but it would also break gaming, VoIP and video calls (WhatsApp, Zoom and similar). On a live customer network that’s not a good trade.

3. Trace the customer behind a notice

To link a future notice to a specific customer, temporarily log the torrent-detection mangle rule:

/ip firewall mangle
set [find comment="<your torrent detect rule>"] log=yes log-prefix="TORRENT-DETECT: "

Each log line includes the internal IP and MAC address. Match the notice’s timestamp against the session tables at that time:

PPPoE: /ppp active print, or PPPoE → Sessions and Acct Logs in ISPMan.
Hotspot: /ip hotspot active print, or Hotspot → Sessions and Acct Logs in ISPMan.

4. Automate repeat-offender handling (optional)

For ongoing enforcement, a scheduled RouterOS script can replace per-packet logging:

Every few minutes, find active connections with the torrent connection mark.
Resolve each source IP to a PPPoE or hotspot user.
Count a “strike” for each check window a user is caught in.
Past a threshold, add the user’s IP to a torrent-suspended address list.

Then drop traffic from that list:

/ip firewall filter
add action=drop chain=forward src-address-list=torrent-suspended comment="Torrent: drop repeat offenders"

Hardening tips:

Give torrent-suspended entries a timeout (for example timeout=1h). Hotspot IPs change often, and a stale entry could block the wrong customer later.
Watch for false positives. Some games and WebRTC apps open many connections; tune the threshold if customers complain.
Check /ip firewall filter print for duplicate rules added during setup.

5. What to tell the site owner

What’s solved: heavy, persistent torrent users are detected and cut off automatically on both PPPoE and hotspot, which greatly reduces notices.
What isn’t: short or occasional encrypted torrenting can still slip through. That’s inherent to firewall filtering.
For any future notice: match its timestamp against the detection logs and session records, then apply your acceptable-use policy (warning first, suspension for repeat offences).
The realistic goal is “detect, reduce and enforce”, not “eliminate”.

Checklist

Rule counters checked: blocking is active.
FastTrack ruled out.
Encryption gap explained to the site owner.
Temporary logging used to trace the specific incident.
Repeat-offender script and enforcement rule in place, with no duplicates.
Timeouts set on suspension entries.