MikroTik

we have tested client with BITCOMET p2p program using p2p filter on MT version 2.9.11. p2p filter recognize only up to 20% of the BITCOMET traffic. Is it possible to improve p2p recognition?

Hi all,

when this parameter is in "on" or "auto" state:

protocol header encrypt (Anti BT protocol filter): auto

MT is not able to detect p2p traffic. When we switch it off, MT catch all BITCOMET traffic.

we have tested client with BITCOMET p2p program using p2p filter on MT version 2.9.11. p2p filter recognize only up to 20% of the BITCOMET traffic. Is it possible to improve p2p recognition?

Usually P2P traffic must be marked with a connection mark.
It's only possible to detect a small part of the connections but if you mark them with a connection mark their connections will be marked from then on.
And usually if you block this traffic then usually the p2p software will default to different ports and perhaps different behaviour leaving you with no ability to detect them.

Has anyone tested latest BitComet client with MT V 2.9.14 ??
Can it be blocked ?

It would be useful to know what is MT's company take on support for handling new P2P programs as they are becoming more evasive.

mikrotik does not develop p2p filters, I think they use external filters from http://ipp2p.org/ This guy was first to report bitcomet encrypted headers detection.

Would something like this work ? when the Mikrotik box detects the 20% of p2p ,get the firewall to randomly drop packets from the source ip increasing the amount of packets dropped minute by minute....then when p2p stops ,remove/disable the rule

mikrotik does not develop p2p filters, I think they use external filters from http://ipp2p.org/ This guy was first to report bitcomet encrypted headers detection.

No, we don't use that filter. We have made our own implementation of the p2p matching.

let me apologize, of course there is no way how would I know this.

I clearly stated in my post : "I THINK..." - once again, please accept my deepest apologies for this, I didn't mean anything bad. I was just plain wrong. We highly rate your RouterOS product, we bought several dozens licenses last year and we are very satisfied.

Best regards to all!

Is there a way to just completely block BITCOMET? Better yet only block it if its encrypted?

Matt

Is there a way to just completely block BITCOMET? Better yet only block it if its encrypted?

Matt

Good question indeed, I have been testing with MT2.9.22. With a simple foward rule that takes all traffic source address LAN and matches "all-p2p" then ICMP rejects it.

Only effective 20% of the time.

How do we get a better p2p filter to work with bittorrent, ed2k etc?

Is there a way to just completely block BITCOMET? Better yet only block it if its encrypted?

Any further info on this? I think the feature to drop any encrypted p2p and only allow unencrypted p2p that can be rate limited would be killer.

Matt

Is there a way to just completely block BITCOMET? Better yet only block it if its encrypted?

Any further info on this? I think the feature to drop any encrypted p2p and only allow unencrypted p2p that can be rate limited would be killer.

Matt

Indeed I have no further information on this, can we get some guidance for a P2P filter rule that is more effective?

geoff

Here are a few tips for those trying to filter p2p.

Use mangle rules! Try this:

IP->Firewall->Mangle - Chain=prerouting Protocol=tcp P2P=allp2p Action=mark-packet New Packet Mark= P2P Passthrough=yes
IP->Firewall->Mangle - Chain=prerouting Protocol=udp P2P=allp2p Action=mark-packet New Packet Mark= P2P Passthrough=yes

This will mark all packets that are detected as p2p packets during the prerouting proccess (before the packets enter the firewall)

**Edit**
It is always a good practice (if you REALLY want to block p2p) to put the rules you are using at the top of your firewall list. This can be done using the Winbox tool.

Once this is done, you can add rules in your simple queues to lower the speed of p2p traffic using the packet mark you created called "P2P"

Also, you can add further filter rulles such as this:

IP->Firewall->Chain=forward P2P=all-p2p Packet Mark=P2P (or whatever you called your packet mark) Action=drop

Using these rules you should be able to succesfully drop most, if not all packets that are detected as p2p. Mikrotik carefully scans the packet headers to determine what type of packets flow through the router.

It is always best to do your packet marking and mangling in the "prerouting" chain.

Using this simple set of mangle rules and queueing rules, all bittorrent and other p2p traffic should be eliminated.

There is *NO* way to limit or classify Encrypted P2P traffic at this point.

Useing a firewall rule like this

add chain=forward p2p=all-p2p action=drop

Will drop Unencrypted and encrypted traffic.

Use mangle with p2p=all-p2p will not mark encrypted p2p traffic.

This is straight from MT:

Hello,
when p2p connection is beeing established some first pacets go unencrypted, so
if you manage to drop them you block it that way.

Regards,
Janis

Beccara <Beccara@> wrote:

> > Ok i will try this,
> >
> > But i dont understand how you can "drop" encrypted p2p traffic but cant
> > identify it for mangle.
> >
> > MikroTik Support [Janis] wrote:
>> > > Hello,
>> > > if you are facing encrypted p2p traffic only way to prioritise is to make
>> > > rules that set higher priority for all other traffic and that whats left set
>> > > low priority, it is like setting http then ftp, e-mail etc becose you cannot
>> > > identify encrypted p2p trafic.
>> > >
>> > > Regards,
>> > > Janis
>> > >
>> > > Beccara <beccara@> wrote:
>> > >
>> > >
>>> > >> I dont want to drop P2P traffic i want to alter its priority
>>> > >>
>>> > >> MikroTik Support [Janis] wrote:
>>> > >>
>>>> > >>> Hello,
>>>> > >>> pleace alter your configuration:
>>>> > >>>
>>>> > >>> 1)reamove all your p2p mangle rules
>>>> > >>> 2) add filter rule that detects whtere it is p2p packet and if it is then drop
>>>> > >>> it
>>>> > >>>
>>>> > >>> that way you should achieve 100% p2p drafic drop
>>>> > >>> and p2p is packet type not connection type
>>>> > >>>
>>>> > >>> Regards,
>>>> > >>> Janis

[/quote]