Solution 1:

I think most approaches that ask "How do I lock down X" are just plain wrong. It's badness enumeration.

Now go downvote me but I think that you should (as you do with "normal" firewalls) just allow the traffic that matches known good traffic. But now you have a problem, SSL encrypted HTTP traffic isn't as easy to allow. There are solutions to it that are effectively a man in the middle attack so if you don't have total control over the clients and signed contracts where people accept being snooped on you might face legal charges (in some countries that is totally forbidden by law, some countries allow such terms in contracts).

To me the only sane level where you want to differentiate between P2P and normal traffic is an application firewall. There's no way for a firewall at the IP or transport layer to sanely make decisions on wether the actual payload is a valid request or not.

Solution 2:

Been there, tried that. Just won't work. In a SOHO environment, such as where I work, there is no way to tell what is P2P and what is "legitimate" traffic, as the gear we have just isn't that sophisticated. The only way I have found that's worth anything at all is a more "manual" way.

My monitoring system (Nagios) alerts me when the traffic on the external interface of the firewall stays above a preset point for more than two consecutive check periods, which are 5 minutes apart. When this happens I have a look at the live traffic display on the firewall (Smoothwall) management interface and if I see a particular machine with a fairly continuous traffic flow to or from the Internet I have a remote look to see what's running on that machine. If I see something that I know is a P2P client I'll pay that user a visit.

This is pretty crude but, and this is a pretty important point, it's the best I can do with what I have available to me.