Re: [LARTC] How to fight with encrypted p2p
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@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Route optimization.
Is there prior work or examples on setting up a router to perform route optimization for customers (such as using traceroute, etc.)? I recently came across a vendor that has implemented a Cisco appliance that does this . . . it watches customer traffic and then sets about trying to optimize the route the customer's traffic takes. Stonie Cooper Planetary Data, Incorporated 402-663-6599 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ipp2p: Unaligned access in search_all_ed2k on sparc64
Jaime Fordham wrote: But ipp2p does compile with Kernel 2.6.22, only it produces these "unaligned access" errors for the "search_all_ed2k" class. Google say me that need a patch (that work here) http://kambing.ui.edu/gentoo-portage/net-firewall/ipp2p/files/ipp2p-0.8.2-kernel-2.6.22.patch Michele ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] tc doesn't shape correct
none of these changes corrected my problem. Stanislav Kruchinin wrote: Johan Huysmans wrote: Here is my tc config, maybe something is wrong with that config: /sbin/tc qdisc del dev bond1 root /sbin/tc qdisc add dev bond1 root handle 1: htb default 1 /sbin/tc class add dev bond1 parent 1: classid 1:1 htb rate 1000mbit burst 1310720 /sbin/tc class add dev bond1 parent 1: classid 1:2 htb rate 30mbit burst 39321 /sbin/tc class add dev bond1 parent 1: classid 1:3 htb rate 10mbit burst 13107 I think you should try to set "quantum" parameter of all leaf classes to the value at least as high as MTU, e.g. 1500 for Ethernet, and to increase the burst of 1:3 class. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] How to fight with encrypted p2p
-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@mailman.ds9a.nl > 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@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ipp2p: Unaligned access in search_all_ed2k on sparc64
But ipp2p does compile with Kernel 2.6.22, only it produces these "unaligned access" errors for the "search_all_ed2k" class. Jaime. Vaidas M wrote: Hmm I think this is compatibility problem before kernel and ipp2p As I remember original ipp2p doesn't compiles with 2.6.22, maybe r4 should..hard to say. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jaime Fordham Sent: Monday, December 03, 2007 11:40 AM To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] ipp2p: Unaligned access in search_all_ed2k on sparc64 Hi, ipp2p 0.8.2.-r4 is a Gentoo Linux "ebuild" which downloads "http://www.ipp2p.org/downloads/ipp2p-0.8.2.tar.gz" and then compiles the kernel+iptables module from source so I would assume that it is the version you mention. Any thoughts on the unaligned access? Jaime. Vaidas M wrote: Where did you get ipp2p 0.8.2-r4? What's the difference from release for version 0.8.2 27.09.2006 ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jaime Fordham Sent: Sunday, December 02, 2007 7:37 PM To: lartc@mailman.ds9a.nl Subject: [LARTC] ipp2p: Unaligned access in search_all_ed2k on sparc64 Hey guys, I've just built a sparc64 (Ultra/5) based firewall with ipp2p compiled as a module and I'm constantly getting the following message in my logs: Kernel unaligned access at TPC[100f8490] search_all_edk+0x20/0x4c [ipt_ipp2p] I'm running the following versions: - Kernel 2.6.22 - ipp2p 0.8.2-r4 - iptables 1.3.8-r1 Any thoughts? ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] tc doesn't shape correct
Johan Huysmans wrote: > Here is my tc config, maybe something is wrong with that config: > > /sbin/tc qdisc del dev bond1 root > /sbin/tc qdisc add dev bond1 root handle 1: htb default 1 > /sbin/tc class add dev bond1 parent 1: classid 1:1 htb rate 1000mbit > burst 1310720 > /sbin/tc class add dev bond1 parent 1: classid 1:2 htb rate 30mbit > burst 39321 > /sbin/tc class add dev bond1 parent 1: classid 1:3 htb rate 10mbit > burst 13107 I think you should try to set "quantum" parameter of all leaf classes to the value at least as high as MTU, e.g. 1500 for Ethernet, and to increase the burst of 1:3 class. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ipp2p: Unaligned access in search_all_ed2k on sparc64
Hi, ipp2p 0.8.2.-r4 is a Gentoo Linux "ebuild" which downloads "http://www.ipp2p.org/downloads/ipp2p-0.8.2.tar.gz"; and then compiles the kernel+iptables module from source so I would assume that it is the version you mention. Any thoughts on the unaligned access? Jaime. Vaidas M wrote: > Where did you get ipp2p 0.8.2-r4? What's the difference from release for > version 0.8.2 27.09.2006 ? > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Jaime Fordham > Sent: Sunday, December 02, 2007 7:37 PM > To: lartc@mailman.ds9a.nl > Subject: [LARTC] ipp2p: Unaligned access in search_all_ed2k on sparc64 > > Hey guys, > > I've just built a sparc64 (Ultra/5) based firewall with ipp2p compiled > as a module and I'm constantly getting the following message in my logs: > > Kernel unaligned access at TPC[100f8490] search_all_edk+0x20/0x4c > [ipt_ipp2p] > > I'm running the following versions: > > - Kernel 2.6.22 > - ipp2p 0.8.2-r4 > - iptables 1.3.8-r1 > > > Any thoughts? > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] tc doesn't shape correct
Here is my tc config, maybe something is wrong with that config: /sbin/tc qdisc del dev bond1 root /sbin/tc qdisc add dev bond1 root handle 1: htb default 1 /sbin/tc class add dev bond1 parent 1: classid 1:1 htb rate 1000mbit burst 1310720 /sbin/tc class add dev bond1 parent 1: classid 1:2 htb rate 30mbit burst 39321 /sbin/tc class add dev bond1 parent 1: classid 1:3 htb rate 10mbit burst 13107 /sbin/tc filter add dev bond1 parent 1: protocol ip prio 0 handle 1 fw flowid 1:2 /sbin/tc filter add dev bond1 parent 1: protocol ip prio 0 handle 2 fw flowid 1:3 Any help appreciated! Johan Huysmans wrote: Hi All, I'm configuring my natting-firewall to do some tc shaping. Some traffic has to be shaped on 30mbit, some on 10mbit all the others are unlimited. The configuring and filtering works correctly. The traffic that is shaped at 30mbit is correct, but the traffic that is shapped at 10mbit only gets to 100KB/sec. It is on a device configured with bonding (both in and out interface). Any clue why shaped traffic at 10mbit only gets to 100KB/sec and not faster? Thx for any response, Johan Huysmans ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
