Weird peer-to-peer behavior?

RouterOS General
1

In my firewall, just ahead of my final DROP statement on the input chain, I have an optional LOG action so I can see what is getting dropped. I turn it on from time to time and review the output to make sure I am not accidentally blocking traffic I should be allowing.

Recently, I have been seeing messages such as the following on one neighborhood router:

DROP input: in:AP out:(none), src-mac 00:02:6f:9b:ff:ea, proto UDP, 10.2.1.28:55133->10.0.0.2:51006, len 122

The source is my AP port, the source IP belongs to a subscriber whose kids I am pretty sure use torrents, but the target is the loopback address of the router. I don’t understand why a file sharing program would be whacking at the router’s loopback address (certainly the router has not advertised itself as a source of torrent material), and I don’t know if I should be concerned about this.

Even more strange, I also see this:

DROP input: in:Feed out:(none), src-mac 00:0c:42:76:3c:9c, proto UDP, 10.4.1.3:58668->10.0.0.2:53634, len 80

The source and source MAC belong to my core router, and the IP address shown belongs to a subscriber on a completely different neighborhood router – again, one with a kid that I am pretty sure uses torrents. To me, it’s extremely spooky that a subscriber in a different town is doing a “reach-around” through the core router to whack on the loopback address of a neighborhood router that isn’t even one that his traffic goes through.

In the end, I am, after all, dropping this particular traffic. But I’d like to know just to satisfy my curiosity what this torrent software thinks it is doing, and whether these messages indicate a larger problem that I should be addressing – perhaps some traffic that I ought to be looking for and blocking, but currently am not?

2

I’ve seen it where people have connected to proper private trackers - possible over VPN connections - and were told about private IPs as valid other endpoints. Then they tore down the VPN connection but left the torrent app running, which was continuing to try and hit those private IPs, but with the VPN connection down were now passing that traffic out via their normal WAN interface. In your case it’s a private IP that exists on a router loopback, so that’s where it ends up.

Wild, wild guess.

3

Fewi’s guess is close if not spot on.

The issue is someone is announcing a private IP (10.0.0.2) into a tracker, so client’s are trying to connect to it. This can be caused by private VPN based trackers, a client with bad NAT detection, or someone trying to seed from the same LAN as the tracker.

This is not an attack aimed it your specific tower, it just happens that your loopback is the same as a common private IP address. If you want to see a lot more similar traffic, set a log to capture all UDP packets sent to 192.168.1.100 (linksys default first client IP). It’s nothing to worry about, but a dead giveaway of torrent traffic.

4

Ah, the second explanation is one I can follow. Though it wouldn’t explain why I’m not seeing even MORE bogus traffic aimed at 10.0.0.1, the loopback address of my core router, which should be even more globally popular as a default address for remote SOHO routers, and is eminently addressable by the usual suspects running torrents on my network.

5

A router wouldn’t be participating in bittorrent. 10.0.01 would be a router IP. You’d see traffic to private IPs clients commonly have. Hence the reference to 192.168.1.100, which is the default first IP a Linksys SoHo router issues via DHCP.

6

Of course, that makes perfect sense!