Anti-P2P suggestion: thottle or block connections to default remote P2P or tracker ports

May I suggest the following feature, I am willing to pay extra for it.

When user connects to a remote default p2p port or tracker port (eg 6881-6999 for bittorent), his entire connection is thottled or blocked.

This is much more efficient than trying to use DPI. It works because, while the Torrent client uses a random port locally, it still connects to default ports on other remote peers. That's how I catch downloader on my network by looking at the remote ports.

I would LOVE to have this feature.

Thanks

Well, there's nothing wrong with DPI itself, it detects tracker connections as well as some regular P2P connections regardless of ports used.

Combining this fact with your suggestion brings me to an interesting idea. How about we introduce a new type of penalty? It could be something like this:

If Any of the following DPI categories {P2P, etc} is detected, then
reduce the rule's rate limit to X% of the set rate for the next Y seconds.

Suppose a user attempts to download a torrent. Once this attempt is detected, the whole user's rule is throttled/blocked for some time. This should stop any attempts to use P2P or whatever else you want to eliminate. This would also work with other P2P clients, not just torrents.

What do you think?

Sounds good and practical.

The reason I suggested that was because I have it running on my servers but still get the occasional dmca notice and want to avoid them. I even throttle when connections are over 100.
Blocking/throttling the entire connection would make a difference I think.

Thanks

We have implemented the new way to penalise users who attempt to use P2P. The new build can be downloaded here. Feel free to play with this feature and let me know how it works for you.

yay!
Just received two dmcas on my server. So glad this is out! I'll test it.

Does the throttle go down to 0%? or 10 minimum?

Oh and any way to update without reinstalling the network adapter? Since I am installing remotely it always kicks me out and I have to hard reset it.

0% is allowed, which should stop any activity on the rule for the specified time.

It's possible to replace files without interrupting the connection. To do that:

1. Download this set of files.
2. Stop the BM service and replace BMCore. exe
3. Start the service again
4. Replace the control tool BMGUI.exe on your local computer or server, depending which one you are using.

Thanks, the update went well with those files but they are for 3.09 and do not include the new p2p penalty...

Sorry my mistake, license was expired. I bought new one. and p2p penalty is there.

I hope it works!

thanks Andrew!

Can you confirm th ep2p penalty is applied only to the single user IP and not to everyone. I have Tracking Mode set to Individual IP.

But I am seeing that after few minutes of normal usage the connection is blocked. Sites won't open. When I disable the rule, they open again.

False positives? Or something else?

It's applied per stream (streams are the dynamically created entities when the tracking is on). It's quite strange, could you perhaps e-mail me your rulest as a zipped .DB file?

Also, what were the symptoms like? All streams within a rule were throttled or just some?

During testing we found that, for example when a person uses a P2P application and then quits it, P2P packets may keep coming from other peers for a while, which triggers the penalty over and over again until P2P packets are no longer present.

Thanks I will send the rules by email

Any chance that p2p activity will block everyone's connection by accident? probably not but just checking.

Basically I use my server as normal (its a vpn server) and after few minutes i loose internet. I suspect there might be p2p users on the server but not me.
With BM service disabled, it starts to work again.
With rule disabled it works (the new penalty).

I "think" it works when penalty is set to 1% instead of 0%

thanks

Good news, it was a bug that I have just fixed. Specifying the penalty of 0% ended up in a division by zero, which crashed the core. That's why 1% worked and 0% did not. A really stupid bug.

Here is the fixed update.

YAY!

Good thing I mentioned the 0%
So happy now, I will test and let you know!

thanks!!

Thank you very much for this feature.

May I ask a few questions about using it.

1) What happens after the time in seconds? E.g. default is 60 seconds. If P2P is constant, will the penalty go for 60 seconds then stop, or kick in again. Can you please explain this?

2) I guess that I do not tick P2P under the Advanced/ Even more settings in a rule. I assume that if I tick this the rule will *only* apply when there is p2p traffic.

3) I cap downloads to 8mbps and uploads to 0.5mbps. I want to achieve the following by using penalties. I want to allow some videos from say youtube and downloads (files etc) with a slight penalty, but enough for HD youtube. I want to choke P2P and all traffic to that PC to almost zero. Will this config achieve that?
(I know it is like - how long is a piece of string.. But any suggestions are welcome)

100% for normal traffic.
Then Penalties of
50% for long transfers and large transfers
10% for greater than 150 connections
5% for P2P

Thanks (for your response and this feature)

Hi Tony,

With the P2P penalty and 60s, the user is always penalised for 60s after the last P2P packet was detected. For example, if the user keeps running a torrent app, there normally will be at least one P2P packets every 60s, so the user is penalised until the torrent app is closed. Once the torrent app is closed and consequently no P2P packets have been seen for 60s, the penalty is removed.

You should not tick P2P in Even more advanced settings. This is because turning this option on causes the rule to apply only on detected P2P packets, which means undetected P2P and other data never will be processed by this rule.

All in all, this set

Quote

100% for normal traffic.
Then Penalties of
50% for long transfers and large transfers
10% for greater than 150 connections
5% for P2P

means that normal browsing activities go unrestricted, long and large connections are reduced to 50% (this applies to individual TCP and UDP connections), opening more than 150 connections reduces rule's limit to 10% and an attempt to use P2P leaves the user with 5% until the P2P activity is no longer seen.

Excellent. Thanks Andrew.