multiple connections from an IP

[migmone]

I was looking through my firewall's connection list (Sunbelt/Kerio). Though I've limited uTorrent to 200 connections, there are usually upwards of 250+ connections.

I found that there are a few IPs which have incoming connections from multiple ports, sometimes 10-15 ports in a narrow range of 100-200 from the first port. This looks very suspicious. Especially since those IPs don't appear in any of my torrents as a connected peer in uTorrent. These IPs have also transmitted in total (up OR down) only tiny amounts of data (100's of bytes).

Please correct me if I have misunderstood: I think the ONLY legitimate reason an IP would make multiple incoming connections/ports to my uTorrent is if it was connecting to more than one torrent. If the IP with multiple ports, doesn't appear as a peer in any torrent, then it would be beneficial to block it at the firewall level to free up dead/unused connections, right? Then more legitimate (read: wants to really share) peers can connect.

I blocked a few IP's and my total connections have come down to more reasonable levels. Downloads on two torrents which were excrutiatingly slow for weeks are now at max speed (don't know if this is a direct effect of blocking). If this turns out to be true, it may be useful for those using ipfilter.dat or firewalls -- not as a security measure, but as a technique to boost up/down speeds.

Any thoughts, experiences or advice are much appreciated.

[DreadWingKnight]

1> How many of these "Connections" are listed under UDP?

2> What connection states are these "Connections" in?

[migmone]

1) very few. Most are TCP with a tiny smattering of UDP

2) I'm not sure about connection states -- there isn't specific info in the firewall nor details other than local ip/port, remote ip/port, incoming or outgoing connection, protocol (tcp/udp/etc), speed in/out, and bytes in/out. I have noticed that these connections hang around for a LONG time, so they aren't being initiated/negotiated.

What other tool could I use to better monitor the states of these suspicious connections?

Unfortunately, there doesn't seem to be a way to break an already established unwanted connection in the firewall. Adding a firewall rule only blocks a future connection.

Just before anyone asks, I'm doing this in the firewall, and not ipfilter.dat, because I want to save system resources/connections at the earliest point possible. Technically, that would be the router, but that's not really feasible or flexible, so this is the next best thing.

[Switeck]

TCP View, for when you really have to play God with your connections.

I've found old BitComet clients (and clones) often attempt multiple connections even for single torrents. It's REALLY nasty when they're only running 1 torrent with few seeds/peers, as they will retry you MUCH faster that way.

It may be those old, broken clients you're blocking that's "saving" so many connections.

[migmone]

Used TCP View. The list of connections is quite different from what is seen in the firewall listing. TCP view isn't showing the multiple connections from the IP addresses that are seen in the firewall's list. Under the assumption that TCPview is more accurate, it would seem that the firewall's display is at fault??? But blocking the IPs results in hundreds or thousands of blocked connections, many times hammer-like, from those IPs. So there must be some merit in the firewall's list, right?

With TCP view, I see something else which is disturbing. There are many System processes with the TIME_WAIT status from the same external IP and SAME PORT! What the...?!? If a client is hammering away with multiple requests, the port would keep incrementing right? At least that (incrementing port numbers) was what I was seeing in the firewall display

Is there a way in uTorrent (1.7.7 or 1.8 beta) to blanket block broken clients, rather than time consuming manual IP blocks? IP addresses keep changing, but the client broken client names do not.

[Firon]

You know, even if you block the connection, it's still going to go through the process of TCP handshakes and closing the connection.

And really, unless your internet is not working, you shouldn't be worrying too much about a lot of TIME_WAIT connections. But it's likely a problem with Outpost, since it's not the first time I've heard of people complaining about it.

[Switeck]

TCP View isn't good at handling special packet types. Even UDP is really only handled for outgoing...though they're technically connectionless, so you'd only have a listening port for UDP.

Like Firon said, TIME_WAIT states get left behind even for failed/closed connections...often by the firewall not releasing them.

[hermanm]

I noticed on my WRT54GL (Tomato firmware) there were a lot of TIME_WAIT connections, so I reduced the drop connection time. Seems to make the router less bloated.

[migmone]

Thanks for the replies. The summary seems to be: don't really bother, it takes care of itself. Now I shall go forth and continue to torrent!