Ok, let’s start this new topic and concentrate all our knowledge (or only your knowledge) here. I spend 6 hours reading about the control (limiting and blocking) of P2P connections but nothing seems to work well…so, all i want is all of your experiences and what you do to manage this big problem like what is the best rule to apply in any situation. I test everything and allways something manage to evade the rules. When I say “I try everything” I mean EVERYTHING. So, let’s start this battle and hope for a solution for all of us.
Regards
If you seriously want to ban P2P traffic on your network, then the best tool you’ve got is your own eyes and brain. Graph the traffic for each of your customers and then do periodic spot checks of those graphs. P2P traffic leaves patterns you’ll learn to recognize and if you’ve got connection tracking turned on, you’ll quickly learn to spot the mess it leaves behind even after it’s been turned off. When you spot it, that customer is now an ex-customer, or if you’re feeling generous, give them one warning before they loose their account and make sure you talk to the parents.
When I was fighting this kind of thing, I found that most cases were kids having fun with parents not knowing what they were up to. When the parent would call in and ask why their account had been suspended, I’d explain why and suggest they talk to their kids. More often then not they called back and confirmed their darling children had downloaded this “really neat program” they’d heard about at school and turned it loose.
This assumes you’ve actually got the authority to terminate customers and that your AUP warns them that P2P traffic isn’t allowed. If you don’t have that authority, don’t waste your time chasing them, it’s a sure way to stress yourself out for no gain.
I have sent in multiple supouts on this, so no default “Send in a supout!” It appears encrypted P2P bandwidth is invisible to Mikrotik queues. Take a look at the interfaces and we’ll see 3 Mbps of traffic going through but look at simple queues and only 20kbps is happening. Running torch shows the IPs repsonsible for the bandwidth and further limiting them has zero effect.
So not only can P2P bandwidth not be throttled, it can’t even be shaped! Any solutions for this?
UniKym: you dont want your customers think you are a dictator, im a ISP and have the power to terminate customers but i dont want to be like Fidel Castro, just want to control them, giving them the feeling that they can do whatever they want but controling them so they do what they whant but in my way. So the Customer is happy and we can manage our network in our way. I think this is what every ISP want.
Control is best than block
Sorry for my english i whrote the best i can.
Have you ever thought about the resources it takes for control attempts?
Given we’re in the MikriTik Forum, it’s reasonable to believe we’re talking about P2P traffic over wireless. Ok, think about what that traffic looks like compared to normal residential traffic. Your normal user is going to establish a connection, transfer data, then close it down. Their browser might even have several connections open at a time. Because it’s initiated by the user, there is a throttleing that takes place, they don’t saturate your AP, especially when they’re not in front of the computer.
Now look at what P2P traffic does to you. To even try to shape or drop it, you’ve got to turn on connection tracking in the Router O/S and that burns resources. Their P2P application forces them to act as a server, so you’ve now got a flood of incoming connections trying to get to that customer, possibly a violation of your AUP if you don’t allow customers to run servers. These connections attempts are going to keep the radio busy during every poll cycle and the more popular the material they’re sharing the worse it gets. That one customer begins to monoplize your AP because such a high percentage of the traffic is for them. This is not going to make your other customers happy, I took a fair number of calls about AP’s being run into the ground by one or two P2P users to the exclusion of the other 60 paying users.
If you want to try to control it instead of block it, now you’ve got the resource usage of the queues as well, and the fact that you’re in an arms race that you’re usually going to be behind in. Just to try to stay even you’ll have to install each new O/S version that comes out and pray that you don’t get bit by some bug that drops your AP offline.
Oh yeah, as you burn more resources for blocking/controlling, decrease the number of customers you can support through that AP as well. If they’re running a CPE112 with limited memory as their client, or some CPE with similar issues, you’ll also get more support calls complaining about their CPE going dead or they can’t browse the web, all because the CPE’s connection table is full of P2P connections.
P2P traffic effects all areas of your network and company, sometimes in ways you didn’t realize. How much is your time worth? Enough to get into an arms race with the P2P application writers? Enough to have to upgrade hardware or add more AP’s than you expected to need?
It’s an ugly mess and it’s only going to get worse as the legit uses of P2P become more and more common.
I dont share your thought but is a valid way to resolve the problem, dont worry about resources thats not the problem. I only ask for another way of control, not for 100% of control but the best who any as used.
You dont really need connection tracking on the CPE do you? Turn it off and save yourself tons of resources at least there. If your blocking p2p at the CPE directly then maybe …
Sam
Idealy you’d want blocking at both ends of your network. Blocking at your border router would prevent all the incoming connection attempts from messing with your network and that machine probably has more horsepower than your AP’s. Blocking at the AP would prevent the user from hogging the AP.
And for blocking, you need the connection table enabled.
We also have problems with P2P, we use a M$ ISA behind our Mikrotik to try to block it. And even now some people get torrents out here and there. Good thing that our ISP shapes our traffic(I live in south africa) So the chances of P2P killing a line is pretty small. You general speed is 10KB/s on a 1Mb line.
Since speed limiting on some p2p is impossible, I thought that limiting the number of p2p connections per user would fits better. Is that even possible? 
I know this is offtopic, but best results I’ve got is with another linux box, and iptables patched with layer7 filter. Yes, it’s not as easy as mikrotik, and setup is not easy at all, but I’ve got rid of almost all p2p traffic.
Care to share what you did to block the traffic? Are you able to shape it as well?
Block it dont waste your time controling it ..
you know that you can gooogllleeee it a little bit and find all the port’s used by clients on torrent, dc++, emule etc…
then tag all the connection (connection mark) w/ some mark … P2P_CONNECTION and then shape it 
…
or ban all port and let only smpt, pop3, imap and http (https) and other by request of user (MSN, ICQ, … )
Yes, I’m able to shape the traffic, and to block almost any P2P:
here is complete howto: http://gentoo-wiki.com/HOWTO_Packet_Shaping
If you want to shape the traffic, you will have to patch kernel source tree with IMQ patch. After that, you will have to set your own rules for QOS. If you want to be able to mark P2P traffic, you’ll have to patch iptables with L7 filter. This way you can mark P2P traffic, pass it to IMQ, and “slow it down”, or simply drop it. Anyway, all is written in this FAQ.
If you simply want to DROP all p2p traffic, IMQ is not necessary.
Finally, all of this above is a lot of work to do and to fix it correctly. If you REALLY don’t need it, don’t do it, you will waste alot of time and effort.
You have this in mikrotik, but i think mikrotik doesn’t “recognise” packets so well as does iptables+L7
very good link… thanx alot
It appears encrypted P2P bandwidth is invisible to Mikrotik queues.
correct, partially. Encrypted bittorrent is seen by MT, but as with some other p2p protocols and their detection, you can just drop it and not bandwidth limit p2p connections. Reason is simple : you DON’T have way how to mark packets “these are encrypted bittorrent packets” so you can’t shape them afterwards.
\
Take a look at the interfaces and we’ll see 3 Mbps of traffic going
through but look at simple queues and only 20kbps is happening.
this could be caused by some other things - like direct communication between associated clients. Have you done default-forwarding=no ? If not, your radio clients can communicate direct between them without your server knowing this.
\
Running torch shows the IPs repsonsible for the bandwidth and further
limiting them has zero effect.
So not only can P2P bandwidth not be throttled, it can’t even be shaped!
these statements are not correct at all. You can limit / shape whatever traffic, p2p or not p2p, encrypted or not. If shaping does not work for you, you are definitely doing something wrong. Two notes :
a) if you try to shape some traffic to very low bandwidth, like 30kbps, shaper is not able to shape this very precisely and exactly.
b) you are not able to shape encrypted p2p protocols. That’s whats encrypting is for - hiding real content from you.
c) shaping p2p to very low numbers does not work precisely and may appear to not work at all.
p2p is definitely the biggest hassle in last years and we fight it day and night. There are some partial solutions:
-
limit each customer to bandwidth they bought. If you sold him 512kbit/512kbit, limit his line to these numbers and let him do whatever he wants to do. Does he want to download p0rn? Ok, let him be. Does he want to use p2p? Fine, you have to be prepared for that. Of course, this brings another thing in: you have to have reasonable oversell ratio. If you sold 100x megabit connection to your customers and you have only 10Mbit internet connection, you deserve nothing good.
-
account traffic each customer is doing with /ip accounting (very very painful to collect, download from server, process and make some solution on this. On the other hand, you will see many things here) or /ip traffic-flow. Export traffic-flow numbers to some Netflow collecting device and analyze what you’ve grabbed. You can then make reports - daily usage, weekly usage per client, etc, etc.
huh, long post. sorry.
Your an ISP, its not your place to block traffic. P2P is not illegal.
If someone is abusing your TOS cut them off, it they have gone over a datacap limit the entire connection.
Its that simple
OMG!!! 
I really got tired reading this topic! It is too long for such problem!
So THE PROBLEM:
p2p=all-p2p option have troubles with some encrypted p2p traffic (it is impossible to find some kind of “pattern” in this traffic, so it is impossible to detect them as p2p!)
MY SOLUTION:
-
I divided traffic for each client into 3 groups:
(a) standard_services (HTTP,FTP,DNS,mails,ICMP,VPN,Telnet,
ssh,HTTPS,SFTP)
(b) standard_p2p (without encryption)
(c) other traffic (skype, VOIP, encrypted p2p, and other) -
For group (c) i created a SFQ queue (SOLUTION ITSELF
) and put limitation on it!
EXPLANATION:
Some of clients run into problem with VOIP communication, because encrypted traffic generated too much connections for group (c) queue (SFQ divided available traffic into too many equally small pieces).
I got some calls about this, and my answer was simple - “Please, disable encryption on your p2p and your voip, Skype, on-line game server will work fine!”
MacGiver, give us some more detailed explanation about your way of control. Seems like is a good solution in the mean time(mean time - mientras tanto o algo asi 
) mikrotik resolve how to shape this traffic. This Topic was 80% about politics of services but that is not the purpose of the topic…so…lets change it and post some solutions(technical solutions)
Regards