what is the firewall rule to block all p2p?
/ip firewall filter add chain=forward p2p=all-p2p action=drop
However this rule will not block any encrypted p2p.
mrz
i want to drop p2p from all other clients except one. is this possible? if its possible then how?
src-address=!client_ip dst-address=!client_ip
You can do it that way, but when someone asks the type of simple question that was asked, it is very likely that they will not understand that answer. A simpler approach would be:
/ip firewall filter
add chain=forward p2p=all-p2p src-address=client_ip action=accept
add chain=forward p2p=all-p2p dst-address=client_ip action=accept
add chain=forward p2p=all-p2p action=drop
That could be simplified with some negative logic rules, as Chupaka did, but I NEVER use negative logic for teaching purposes. 
FWIW, the complete rule that Chupaka was referring to would be:
/ip firewall filter
add chain=forward p2p=all-p2p src-address=!client_ip dst-address=!client_ip action=drop
hmmm… Butch, have you checked these rules?.. I saw somewhere that rules like “p2p=all-p2p src-address=client_ip” (those who check only one direction of tcp traffic, src-address=xxx) match less p2p traffic than bidirectional rules… if that is true, than the most complete solution will be marking all p2p packets, then allow packets to and from the client, and after that drop all the rest
That code would simplify to:
/ip firewall filter
add chain=forward p2p=all-p2p src-address=!client_ip action=drop
add chain=forward p2p=all-p2p dst-address=!client_ip action=drop
The following doesn’t make sense, since the source & destination address would never be the same, unless you want to connect to yourself which would be silly:
really?
let’s examine step-by-step:
client_ip → server_ip: is not dropped, because ‘src-address=!client_ip’ do not match
server_ip → client_ip: is not dropped, because ‘dst-address=!client_ip’ do not match
other_client_ip → server_ip: is dropped, because both conditions match
server_ip → other_client_ip: is dropped, because both conditions match
don’t be confused:
src-address=!client_ip dst-address=!client_ip action=drop
is NOT the same as
src-address=client_ip dst-address=client_ip action=accept
This is the reason I don’t use negative logic when teaching.
This rule simply means to drop peer to peer if the src-address AND the dst-address is NOT the client_ip.
The following are not equivalent:
/ip firewall filter
add chain=forward p2p=all-p2p src-address=!client_ip action=drop
add chain=forward p2p=all-p2p dst-address=!client_ip action=drop
Above will drop if src is not client_ip even if dst is client_ip
/ip firewall filter
add chain=forward p2p=all-p2p src-address=!client_ip dst-address=!client_ip action=drop
Above will drop if both dst and src are not client_ip
So first set of rules will match more traffic than the second.
I don’t use that sort of rule myself. I used it as an example for instructional purposes. I’d believe your contention that a bidirectional rule will capture more traffic is accurate. My personal approach would be something like:
/ip firewall filter
add chain=p2pchain src-address-list=allowp2p action=return
add chain=p2pchain dst-address-list=allowp2p action=return
add chain=p2pchain action=drop
add chain=forward p2p=all-p2p action=jump jump-target=p2pchain
Although I doubt the original questioner would approach it this way. Depending on the other complexities of the existing firewall application, the above is an easy to use approach, however.
this is not working for me. i did /ip firewall filter add chain=forward p2p=all-p2p action=drop
and yet i can download with IDM. what im i missing?
the new version of bittorent doesn’t block 
The built in P2P matcher is old.
The better approach is still to not detect P2P and deal with it, but to deal with all protocols you can easily detect and prioritize and shape, and then deal with ‘the rest’, which will include P2P.
FWIW, this is EXACTLY what my QOS does. It really is the only way. Actually, I do use the p2p matcher first (for that small amount of p2p we CAN detect).
fewi i don’t understand!
What is it that you don’t understand? The P2P matcher is not perfect. The best approach to “detecting” p2p is to identify all things that are NOT p2p and then assume the remainder IS p2p.
AFAIR, p2p matcher is from http://www.ipp2p.org/
p.s. wow!.. a month ago http://www.opendpi.org/ was integrated into the Linux Netfilter! MT, should we wait for the new p2p matcher? =)
This is correct. At least testing shows approximately the same counts between a standard linux install and MT. Also options look the same.
p.s. wow!.. a month ago > http://www.opendpi.org/ > was integrated into the Linux Netfilter! MT, should we wait for the new p2p matcher? =)
Without a doubt that would be very cool!