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.
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.
-
-
believewireless
Member Candidate
- Posts: 231
- Joined:
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?
So not only can P2P bandwidth not be throttled, it can't even be shaped! Any solutions for this?
-
-
Testingpepe
newbie
- Posts: 42
- Joined:
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.
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.
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.
-
-
Testingpepe
newbie
- Posts: 42
- Joined:
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.
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.
-
-
believewireless
Member Candidate
- Posts: 231
- Joined:
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, ... )
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:Care to share what you did to block the traffic? Are you able to shape it as well?
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
> 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.
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.
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:
1) 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)
2) 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!"
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:
1) 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)
2) 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!"
-
-
Testingpepe
newbie
- Posts: 42
- Joined:
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
) 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
-
-
Testingpepe
newbie
- Posts: 42
- Joined:
I dont find the final solution, that's why I start this topic.
This is the one Im using now:
Mangle
0 chain=prerouting protocol=tcp p2p=all-p2p action=mark-packet
new-packet-mark=p2p passthrough=yes
1 chain=prerouting protocol=udp p2p=all-p2p action=mark-packet
new-packet-mark=p2p passthrough=yes
Filter
2 chain=forward packet-mark=p2p p2p=all-p2p action=drop
Some of the traffic dont get drop just go to the queue (like 10kbps) and others get free pass.
But is the best i can find testing a lot of rules
This is the one Im using now:
Mangle
0 chain=prerouting protocol=tcp p2p=all-p2p action=mark-packet
new-packet-mark=p2p passthrough=yes
1 chain=prerouting protocol=udp p2p=all-p2p action=mark-packet
new-packet-mark=p2p passthrough=yes
Filter
2 chain=forward packet-mark=p2p p2p=all-p2p action=drop
Some of the traffic dont get drop just go to the queue (like 10kbps) and others get free pass.
But is the best i can find testing a lot of rules
Re: P2P the battle for control
That doesn't sound like what you are saying here:
What made you think it was a battle in the first place?
the solution is fairly easy. consider the following;
when in a sequence of tcp packets will you know the tcp session is initiated by a program doing p2p type transfers?
the first packet?
the second packet?
.... any packet after the third?
and then consider; when you identify wether it's a p2p related tcp session then what do you do about it?
forget about it?
remember it for future reference of that tcp session?
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.
What made you think it was a battle in the first place?
the solution is fairly easy. consider the following;
when in a sequence of tcp packets will you know the tcp session is initiated by a program doing p2p type transfers?
the first packet?
the second packet?
.... any packet after the third?
and then consider; when you identify wether it's a p2p related tcp session then what do you do about it?
forget about it?
remember it for future reference of that tcp session?
-
-
Testingpepe
newbie
- Posts: 42
- Joined:
Lets take a look at the problem in more detail:
1) Each p2p traffic consist of two type connections - "search" and "data" connections
2) Only torrents can be encrypted
3) Encrypted p2p = means "data" connection is encrypted and it is (and will be) impossible to determine that this traffic is p2p
4) "search" connections always will be without encryption
5) if you drop the "search" connection it is impossible to create the "data" connection (even encrypted one)
There are no point to drop all-p2p, you can drop only torrent traffic if you would like to drop encrypted traffic
You should really create a per-user limitation, and then user can do whatever he likes with his connection speed!
1) Each p2p traffic consist of two type connections - "search" and "data" connections
2) Only torrents can be encrypted
3) Encrypted p2p = means "data" connection is encrypted and it is (and will be) impossible to determine that this traffic is p2p
4) "search" connections always will be without encryption
5) if you drop the "search" connection it is impossible to create the "data" connection (even encrypted one)
There are no point to drop all-p2p, you can drop only torrent traffic if you would like to drop encrypted traffic
You should really create a per-user limitation, and then user can do whatever he likes with his connection speed!
Last edited by macgaiver on Wed Aug 09, 2006 3:16 pm, edited 1 time in total.
I use that solution because trying to control them (so far) is not possible. So I block it, but is not working like a full block, then is like a way of control. I think. For the other things you say I dont understand what you want to expose.
OMG, why mangle??? Just use this one rule
/ip firewall filter add action=drop chain=forward p2p=all-p2p
or take a look at my previus reply
/ip firewall filter add action=drop chain=forward p2p=bit-torrent
I know this topic has probably been beat to death. However, the problem we see with P2P is not with the bandwidth. We have each user set to the speed they signed up for and I don't really care what they do with it. It becomes a problem when the connections per second get very high and cause problems with the AP and other customers on the AP. We have set a limit of 100 connections and a few make and exceed that limit. It is those that we turn off until they clean up. It's either a very agressive P2P, a virus, spyware or someone who mangled their winXP SP2 connection limiting to get more connections and faster P2P downloads.
This is the rule I use for that:
add chain=connections protocol=tcp tcp-flags=syn connection-limit=100,32 connection-state=new action=drop \
comment="" disabled=no
This is the rule I use for that:
add chain=connections protocol=tcp tcp-flags=syn connection-limit=100,32 connection-state=new action=drop \
comment="" disabled=no
We use Mikrotik to throttle p2p to a degree but it does not get it all clearly. We also track each users bandwidth consumption and have a quotta we really do not enforce. What I was thinking is that in the future we could throttle all the bandwidth hogs back at peak times but let them go during off peak.
Matt
Matt
Ok, old topic, but very usefull...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:
1) 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)
2) For group (c) i created a SFQ queue (SOLUTION ITSELF
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!"
only, the question is: Could the stuff you sugest be done with PPPoE users ??? And if it could - how?Dejan
