-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. Limiting your rules to specific ports is pretty useless. This has been done before, and it failed miserably. 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. 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. 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. Ask yourself, what is the problem you are really trying to solve. Andrew Beverley wrote: >> I believe that whole question is in topic. >> Is there any way to recognize ( and then shape ) p2p traffic which is encrypted? >> Modern p2p clients have this ability moreover some of them have this enabled by default. >> Now I'm using ipp2p for iptables but as I know this doesn't recognize encrypted traffic. > > One way to do this is to look for the style of traffic. For example, I > look for lots of connections from one PC to port numbers above 1024. > This will also incorrectly recognise some other traffic, but on the > whole it works well for me. > > The following are some examples using connlimit (now included in vanilla > kernel) and ipset (see http://ipset.netfilter.org/) > > # first look for style of traffic and log that client to an ipset > iptables -t mangle -A FORWARD -o ppp0 -p tcp --dport 1024: \ > -m connlimit --connlimit-above 10 -j SET --add-set p2p src > iptables -t mangle -A FORWARD -o ppp0 -p udp --dport 1024: \ > -m connlimit --connlimit-above 10 -j SET --add-set p2p src > iptables -t mangle -A FORWARD -i ppp0 -p tcp --sport 1024: \ > -m connlimit --connlimit-above 10 -j SET --add-set p2p dst > iptables -t mangle -A FORWARD -i ppp0 -p udp --sport 1024: \ > -m connlimit --connlimit-above 10 -j SET --add-set p2p dst > > # then shape traffic above port 1024 for those detected clients > iptables -t mangle -A FORWARD -o ppp0 -p tcp --dport 1024: \ > -m set --set p2p dst -j MARK --set-mark 60 > iptables -t mangle -A FORWARD -i ppp0 -p tcp --sport 1024: \ > -m set --set p2p dst -j MARK --set-mark 60 > iptables -t mangle -A FORWARD -o ppp0 -p udp --dport 1024: \ > -m set --set p2p dst -j MARK --set-mark 60 > iptables -t mangle -A FORWARD -i ppp0 -p udp --sport 1024: \ > -m set --set p2p dst -j MARK --set-mark 60 > > > Regards, > > Andy Beverley > > > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHU98owRXgH3rKGfMRAmszAKCIhVoUnfuWDIaWQqwE1WfuSz9sNwCgipFZ wqrptNaNg3HMFE79AvbQ+fI= =gb3i -----END PGP SIGNATURE----- _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
