SA500 IPS and p2p blocking

Unanswered Question


I have just tested the IPS functionnality on a SA520 (60d free trial), enabling p2p "Detect and prevent", specifically Bittorrent.

After noticing Bittorrent downloads were still going through on the LAN, I contacted my local Cisco support, which tested on their side, and came back to me notifying this feature only blocks p2p "attacks" from the outside (ie, p2p "attacks" arriving on the WAN interface). But a local user firing up his Bittorrent client can still establish TCP sessions and download happily.

Having had a local presentation of the product before buying 7 of them, and according to the documentation, I was under the impression the IPS was doing some packet inspection on all ports to block p2p.

This is not the case, according to my local support. The only way to block p2p would be to use standart firewall rules (ie, blocking TCP/UDP above 1024) which is what I wanted to avoid and not blocking any "guest" user who can reconfigure his machine to use a port < 1024 anyway, on his p2p client.

Anyone knows of any plan to have a real packet inspection on the SA500, to detect p2p patterns and block them, whether from the WAN or LAN ?

In the meantime, documentation should really clarify the term "p2p blocking".

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Steven Smith Tue, 03/02/2010 - 14:47

We have a different IPS signature that will be coming out that will fix this.  I don't have the exact date, but we are looking at mid to late March.

Steven Smith Wed, 03/03/2010 - 08:34

I will do my best to remember.  We are coming out with some new firmware for the SA500, it will be at that time that a new signature file will also be available.

surama123 Wed, 03/31/2010 - 08:03


I have done a considerable amount of testing of IPS to block bittorrent traffic on an ISR router using IPS v5.0 signatures. Although the signatures pick up Bittorrent packets by looking for activity on specific ports the bulk of the file download traffic is on random high ports and does not seem to have an easy signature match. Hence you could block bittorrent using IPS and this would disrupt the user on the LAN but would not prevent the PC participating in a torrent either as a seed or otherwise.

So if you are trying to stop bandwidth abuse, which is what I am concerned about (its someone elses job to prosecute these people for copyright theft right?) then my workaround has been to modify the signatures to 'deny attacker inline'. This has the effect of blocking internet access for any PC that has the bittorrent client installed (I believe this is reset after an hour). Of course the IPS rule is applied outgoing to catch Bittorrent users on the LAN. This will certainly free up your bandwidth from abusers.

I worked with TAC on this case but came to my own conclusions about how to tackle bittorrent effectively. If you have some kind of monitoring bundled with the SA500 you should be able to see the IP of the culprits or anyway you will hear their complaints when they can no longer get online.

I haven't worked with the SA500 before though it looks like an interesting product. I would be very surprised if it uses very different signatures from those available in IOS IPS so I hope you consider my comments valid.

Good luck Cisco working on a match for all P2P traffic (new versions of Skype included), but I don't envy you in this task as the developers of this software are always looking for ways of evading IPS etc.

biraja Wed, 03/31/2010 - 14:55


The latest signature is the now.

Please download it from the following link or you can do auto-upgrade on the SA540.

Can you let us know if this resolves the bittorrent download issue?




I tried the SBIPS000003 signatures, using firmware 1.1.21, Bittorrent downloads are still working just fine from a PC directly attached to LAN port 4 (SA520).

I have checked the options "Enable IPS Protection for LAN" and "Detect and Prevent" Bittorrent.


its someone elses job to prosecute these people for copyright theft right?

--> in France, the owner of the Internet access can be held responsible for copyright theft (HADOPI...) which is why my customers are being concerned.

you will hear their complaints when they can no longer get online

--> user's connectivity is fine when he's downloading, his Bittorrent client/traffic is not being detected



biraja Thu, 04/01/2010 - 10:54

Hi DH,

This will be resolved with forthcoming SA500 firmware release which will be posted in couple of weeks.



surama123 Thu, 04/01/2010 - 13:41

Hello DH,

Interesting what you say about the legal aspect in France. Some of my client connect in that jurisdiction so I will be reminding them (would appreciate any reference you may have to the French law on this).

Could I ask what Bittorrent client your user is connecting with? So far I have only done tests with Miro which uses the Bittorrent protocol for tracking (detected by Cisco IPS) but passes file transfers on high tcp ports (not detected). For that reason I chose to change the event action to 'deny attacker inline' because the client at least produced a number of hits on the bittorrent signature even if the bulk of the traffic used other ports. Does the SA500 series have the option to edit event actions in IPS?

Would be happy to test the bittorrent client you are up against with IPS 5.0 sigs and Wireshark for comparison with the SA500 performance.


Hi Surama,


I did my tests with the Vuze client, using a high TCP port (58xxx) for listening to connections, but the client is being NATed with no port forwarding to that port anyway. It establishes through outgoing connections, I guess.

My IPS configuration (dont think I have a "'deny attacker inline" option):





I guess I'll wait for next firmware :)


Latest firmware (1.1.42) does block some packets, as can be seen in the logs:

[SA520]*DROP*[1:1001209:1] BitTorrent Client Activity [ Reference: ] {TCP} -> x.x.x.x:56867

[SA520]*DROP*[1:1001209:1] BitTorrent Client Activity [ Reference: ] {TCP} -> x.x.x.x:55839

[SA520]*DROP*[1:1001209:1] BitTorrent Client Activity [ Reference: ] {TCP} -> x.x.x.x:51514

But not all, downloads are still working at full speed.

surama123 Thu, 04/22/2010 - 13:57

Correct me if I am wrong but IPS has been dumbed down here in this Small Business Pro product and you do not have the option to deny attacker inline as you do with the IOS IPS available on 800 and above ISRs and the IPS available on Cisco IPS appliances. This is a great pity because, as you are finding, the bulk of p2p traffic does not trigger the bittorrent signature - however the bittorrent client cannot resist occassionally updating its tracker information and to do this it uses the bittorrent protocol which is well documented and does match the IPS signature. If this theory is right for all Bittorrent clients (sorry I havent had time to test Vuze yet) then the 'deny attacker inline' event action is the way to go to enforce a policy that protects your bandwidth and prevents you getting added to a list of IP addresses that is in breach of any national laws that may apply concerning  the 'digital economy.' This is because the blocking action is against the machine that sourced the packet not against individual packets that don't make much difference to your traffic volume.

My suggestion is you upgrade to an 800 series ISR to have stronger tools against P2P. On the other hand maybe Cisco will consider issuing an update to correct this issue....

weilia Thu, 04/22/2010 - 17:55

Hi David,

Could you forward me the .torrent file for us to investigate.
Also, could you let me know which BitTorrent client you are
using and it's version.


weilia Mon, 06/28/2010 - 14:50


Have you tried the latest signature release ? this issue should be fixed by the latest signatures.




This Discussion

Related Content