Bittorrent could use many different ports, so you cannot block by port, and you cannot block by ip-address either, so you might need an additional tool to block it, which could use packet inspection or similar technique.

Cisco or sonicwall firewalls have the abilities to detect bittorrent traffic regardless of which ports were used.

That’s good, but what’s most important to me is whether Cisco or sonicwall firewalls have the abilities “STOP” bittorrent traffic regardless of which ports were used? Please advise. Thanks!

Look into the Netgear ProSecure UTM series of firewalls.
They do have the ability to get that granular in what is blocked and what is allowed.
There is also a yearly subscription you have to purchase that will allow the firewall to update multiple time during the day with new virus, malware and spam DAT files automatically. Excellent units, and priced very reasonably.

When I considered blocking torrents on my network border, I had to ask myself a couple of questions: Can we ban torrents in policy and enforce this policy? Do we need torrents completely banned or we just want them not to be obstructive for normal traffic?

Answers were clear enough – I’m managing an academic network where bans in policy are not welcome and also are hardly enforceable. And then, we are not paying for traffic but for bandwidth (almost nobody pays for traffic nowadays), so while we hold the rein on torrents usage of bandwidth we are OK.

Until recently we had no troubles with torrent traffic but with new versions of torrent clients using UDP they became quite aggressive and disruptive for our “normal” traffic. So, then I had again to ask myself a couple of questions: Can we afford a packet inspection firewall? What to do if we can’t afford it?

The answers were quite clear again – we can’t afford neither hardware appliance nor upgrade of the gate hardware to implement packet inspection in the software… So I went with forbidding the UDP traffic through our gate with a couple exceptions: DNS (port 53) and NTP (port 123). All other normal traffic in our network is TCP – and we don’t use traceroute for more than 5 years now (since we started using hping for real TCP tracerouting). Under these restrictions torrent clients fall-back to TCP and are neither aggressive nor disruptive to our use of the network.

Sure, this is not a silver bullet – probably your organization uses random-port UTP a lot in its day-to-day operations – but this is quite improbable if you are not a torrent operator… )

Hope this helps in answering your own qustions,

Petko