Thanks for sharing. Just one question, how are you implementing the daily limit? Regards, Mario Antonio ----- Original Message ----- From: "the sew" <sewlist@xxxxxxxxx> To: "Andrew Beverley" <andy@xxxxxxxxxxx> Cc: lartc@xxxxxxxxxxxxxxx Sent: Monday, December 10, 2007 8:37:07 AM (GMT-0500) America/New_York Subject: Re: How to fight with encrypted p2p Hi, We had similiar problem with p2p, used ipp2p and L7filter together before and worked well until clients( mostly clever ones) started getting around it with encryption. We have about 700 wireless clients hitting our network and our network was taking big knocks with guys using couple of gigs day on entry level packages. Was going to use Ipoque, but was quite pricy for us, Only solutions for us to use a daily limit of eg 500MB, then they get slowed down to slower speeds, This worked like a charm Out of interest we used freeradius / pptpd|pppd with some custom perl scripts and tc rules Sew On Dec 3, 2007 9:33 PM, Andrew Beverley <andy@xxxxxxxxxxx> wrote: > > I believe "fighting" is the wrong approach. Badly shaping the wrong > > traffic is just as bad, if not worse IMO. An ISP in my neck of the > > woods plays havoc with encrypted mail (SMTP + TLS as well as IMAPS) as a > > result of their P2P fight. Needless to say we no longer use them, and > > we encourage clients, friends, and colleagues not to as well. I don't > > use P2P but I do use ssh, imaps, sftp, and https daily. Screwing with > > these services is not useful. > > Using the rules in the example previously given specifically steers well clear > of these services. > > > Limiting your rules to specific ports is > > pretty useless. This has been done before, and it failed miserably. > > Agreed. > > > For me, if P2P does not belong at all, for instance on a corporate > > network, then a default deny on the outbound works much better. We then > > only allow specific connections on a case by case basis. > > I have seen this work very well on corporate networks, and would > recommend this > approach where possible. Unfortunately though, on a normal home user network, > there are so many different possibilities that this isn't very practical. > > > For instances > > where I am not able to block p2p, I define specific rules for high and > > low priority, and leave everything else in the default. If the end user > > wants to use the bulk of his or her bandwidth for P2P, so be it. Of > > course in this case bandwidth accounting is far more useful. > > Again, this depends on the circumstances. If you only have 2Mbit/s to share > between 100 users then each user cannot have their own 'share' of the > connection. Equally, people downloading in a responsible way are lumped > into the > same category as p2p users, which is not fair. Bandwidth accounting is a > possibility, and something I haven't investigated. > > For those who want to fairly share bandwidth beween users, I would > recommend the > ESFQ patches. These allow bandwidth sharing to be done on an IP address basis, > rather than per connection. This prevents the hundreds of p2p connections from > drowning out single downloads. > > > I would also encourage your users to use software that is or can be well > > behaved. Software that allows you set a proper TOS for instance. If > > possible work with the end users. > > I have personally found that the best solutions are not tech solutions. > > Having a well defined Acceptable Use Policy, plus a constructive > > dialogue with my users has been far more effective than any shaping > > routine I/we could come up with. > > Agreed. However, in a situation where you have a lot of users coming > and going, > it is not easy to educate the many hundreds of users. > > I guess it all boils down to your own situation. Traffic shaping on a > corporate > network or on a network where your users are static can be done using > the above > techniques. However, sharing a small connection between hundreds of regularly > changing users is difficult, and I have found the 'blunt' rules previously > described to work very well with no complaints. > > > Regards, > > Andy Beverley > > > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
