Limiting Peer to Peer Traffic



ImageStream routers support powerful packet matching and traffic limiting techniques in ImageStream Linux version 4.2 and later releases. This document provides examples of identifying and limiting Peer to Peer (P2P) traffic. More in-depth information about the capabilities of the iptables utility is available in other Technical Notes and on the Other On-Line Resources page on this site.

Most, but not all, major P2P networks can be identified using the methods outlined below. ImageStream will be adding support for new P2P networks in future releases as necessary. Currently, ImageStream routers can match traffic from the following P2P networks:
  • eDonkey
  • eMule
  • Overnet
  • Direct Connect
  • KaZaa
  • Gnutella
  • BitTorrent

Theory of Operation

ImageStream Linux version 4.2 or greater supports matching of P2P using iptables rules. Once the ImageStream router identifies P2P packets, the router can add packets to a limited traffic class or a quota. As with other types of traffic, the iptables utility can be configured to drop P2P traffic completely. As with all Quality of Service techniques, the goals of limiting P2P traffic are to more effectively manage limited bandwidth resources, limit unnecessary congestion and prevent network resource abuse. Quality of Service is best managed on interfaces where data is transmitted. To limit P2P traffic, it may be necessary to add iptables rules to both inward-facing and outward-facing network devices. Dropping P2P traffic at the router on an inbound or outbound interface will eliminate all P2P traffic types supported above without the need to add additional rules.

Before You Start

In the example diagrammed above, the ImageStream router has a DS-3 (45 Mbps) connection to the Internet and a 100Mbit Ethernet connection to a local network. The example configuration below will limit a P2P client on the local network to 1 Mbit per second of throughput, but not restrict non-P2P traffic in any way. In this example, the DS-3 is on interface Serial0 and the local network is connected via Ethernet0. The appropriate interface to limit traffic flow decrease downstream P2P traffic is on the interface to the local network, Ethernet0. As noted above, data arriving from the Internet is transmitted to users on Ethernet0.

Limiting P2P traffic has two main steps: classifying P2P traffic and limiting that traffic. For this advanced application, you will use the standards-based Diffserv queuing utility 'tc' together with the iptables utility. The configurations listed in this example may not match the ones suitable for use on your network. Any device names, class identification numbers, bandwidth allocations or link speeds are provided as examples only. You will need to change the commands in the example below to match the settings suitable for your network.

Configuring the Quality of Service Classes for Limiting Peer-to-Peer Clients

Enter the Quality of Service menu and choose the option to configure Quality of Service rules. Enter the following commands in the router's Quality of Service configuration file:
#Set up the Bandwidth Management for eth0
#(traffic transmitted TO users coming FROM the WAN)
tc qdisc add dev eth0 root handle 1: htb

# Setup the root class for all Traffic classes
# rate is set to 100 Mbps.
#The 'ceil' ceiling value is omitted,
#and will be set to the same value as the rate (100 Mbps)
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit

# The class for limited traffic (P2P traffic)
# rate is set to 1 Mbps.  'ceil' is omitted here also.
tc class add dev eth0 parent 1:1 classid 1:17 htb rate 1mbit
# Alternate example: Provide a minimum of 512 Kbps and set a maximum of 1 Mbps
#tc class add dev eth0 parent 1:1 classid 1:17 htb rate 512kbit ceil 1mbit


The set of commands above creates a traffic class, identified as 1:17, that is limited to transmitting at a maximum of 1 Mbit/sec. The first two commands initialize the hierarchical token bucket (HTB) queuing algorithm and are not necessary if a pre-existing htb root class is already configured on this interface. The third command defines the a class id (1:17, with '1' identifying the root class and '17' being a unique identification number selected arbitrarily). The 'rate' keyword sets the bandwidth limit for this class (1mbit). The alternate example shows how to use 'rate' and 'ceil' to create a lower and upper bandwidth limit for the class.

Configuring the Firewall Rules for Limiting Peer-to-Peer Clients

Now that the router has a traffic class to use for limited traffic, you must configure the iptables utility to sort P2P traffic into the limited class. Enter the router's Firewall menu and choose the option to configure Firewall rules. The placement of these commands is important! The use of these commands may require you to remove default configuration settings, insert rules into an existing configuration, or modify current packet marking configurations. For maximum effectiveness, these rules should be placed immediately below any rules that flush/clear existing firewall rules (commands that begin with 'iptables -F'). Enter the following commands in the router's Firewall configuration file for 4.2 distributions:
#Restore any previous connection marks
iptables -t mangle -A PREROUTING -p tcp -j CONNMARK --restore-mark

#Do not remark any packets--Accept any packets already marked
iptables -t mangle -A PREROUTING -p tcp -m mark ! --mark 0 -j ACCEPT

#Mark ALL supported P2P types with a value of 1
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --ipp2p -j MARK --set-mark 1

#Mark ALL packets belonging to P2P connections marked above with a value of 1
iptables -t mangle -A PREROUTING -p tcp -m mark --mark 1 -j CONNMARK --save-mark

#Associate marked packets transmitted on Ethernet0 with traffic class number 1:17
iptables -t mangle -A POSTROUTING -o eth0 -m mark --mark 1 -j CLASSIFY --set-class 1:17
The 4.4 series distributions use the 2.6 kernel and xtables. The syntax for the xt_ipp2p module is slightly different. You must specify the protocols to match on. Protocol types include:
ipp2p v0.10 match options:
  --edk    [tcp,udp]  All known eDonkey/eMule/Overnet packets
  --dc     [tcp]      All known Direct Connect packets
  --kazaa  [tcp,udp]  All known KaZaA packets
  --gnu    [tcp,udp]  All known Gnutella packets
  --bit    [tcp,udp]  All known BitTorrent packets
  --apple  [tcp]      All known AppleJuice packets
  --winmx  [tcp]      All known WinMX
  --soul   [tcp]      All known SoulSeek
  --ares   [tcp]      All known Ares

EXPERIMENTAL protocols:
  --mute   [tcp]      All known Mute packets
  --waste  [tcp]      All known Waste packets
  --xdcc   [tcp]      All known XDCC packets (only xdcc login)
The following example will match on the most common traffic including eDonkey, KaZaA, Gnutella and BitTorrent. Enter the following commands in the router's Firewall configuration file for 4.4 distributions:
#Restore any previous connection marks
iptables -t mangle -A PREROUTING -p tcp -j CONNMARK --restore-mark

#Do not remark any packets--Accept any packets already marked
iptables -t mangle -A PREROUTING -p tcp -m mark ! --mark 0 -j ACCEPT

#Mark ALL supported P2P types with a value of 1
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --edk --dc --kazaa --gnu --bit -j MARK --set-mark 1

#Mark ALL packets belonging to P2P connections marked above with a value of 1
iptables -t mangle -A PREROUTING -p tcp -m mark --mark 1 -j CONNMARK --save-mark

#Associate marked packets transmitted on Ethernet0 with traffic class number 1:17
iptables -t mangle -A POSTROUTING -o eth0 -m mark --mark 1 -j CLASSIFY --set-class 1:17

The first command restores marks on packets as they arrive on the router. The second command ensures that packets already marked are not remarked by these rules.

The third command uses the ipp2p match provided with ImageStream's version of iptables to match all supported types of P2P requests and mark any matched requests with a mark of 1. The packets themselves are not altered in any way. The packet mark value is stored in the router's memory structure used for this packet. The fourth command instructs the router to mark all packets associated with the previously identified P2P requests with a value of 1. This command ensures that all packets, and not just the P2P requests, are identified by the router. This command is not necessary when dropping all P2P requests.

The last command sets the traffic class id on any packets to class id 1:17. This command also contains two critical additions: the first to add only packets marked with a value of 1 and the second to add only those packets that will be transmitted on Ethernet0 (eth0). The limits are important to prevent other traffic from being added to the limited class by mistake. This last command redirects all of the previously marked P2P traffic to the limited traffic class created in the QoS step. Traffic from P2P clients added to this limited class will be limited to a aggregate maximum of 1 Mbps.

Configuring the Firewall Rules for Dropping Peer-to-Peer Traffic

Denying the use of P2P client software on a network routed by an ImageStream router does not require the use of Quality of Service classes. To drop all supported P2P network traffic, the router only needs to identify and discard this traffic.

Enter the router's Firewall menu and choose the option to configure Firewall rules. The placement of these commands is important! The use of these commands may require you to remove default configuration settings, insert rules into an existing configuration, or modify current packet marking configurations. For maximum effectiveness, these rules should be placed immediately below any rules that flush/clear existing firewall rules (commands that begin with 'iptables -F').

Enter the following commands in the router's Firewall configuration file:
#Drop all Peer-to-Peer network traffic
iptables -A FORWARD -p tcp -m ipp2p --ipp2p -j DROP


The iptables rule above will discard any P2P traffic that would normally be forwarded by the router. Users connected to this router will be unable to use the P2P services listed at the top of this page.

Configuring the Quality of Service Classes for Limiting Peer-to-Peer Network Individually

ImageStream Linux can distinguish between different types of P2P networks. The example below limits KaZaa traffic to only 256 Kbps, but places BitTorrent traffic in a separate 4 Mbps queue. To create this configuration, you will create two limited classes and use two sets of iptables ipp2p match rules. Enter the Quality of Service menu and choose the option to configure Quality of Service rules. Enter the following commands in the router's Quality of Service configuration file:
#Set up the Bandwidth Management for eth0
(traffic transmitted TO users coming FROM the WAN)
tc qdisc add dev eth0 root handle 1: htb

# Setup the root class for all Traffic classes
# rate is set to 100 Mbps.
#The 'ceil' ceiling value is omitted,
#and will be set to the same value as the rate (100 Mbps)
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit

# The class for limited traffic (KaZaa traffic only)
# rate is set to 256 Kbps.  'ceil' is omitted here also.
tc class add dev eth0 parent 1:1 classid 1:17 htb rate 256kbit
# Alternate example: Provide a minimum of 256 Kbps and set a maximum of 1 Mbps
#tc class add dev eth0 parent 1:1 classid 1:17 htb rate 256kbit ceil 1mbit

# A second class for limited traffic (BitTorrent traffic only)
tc class add dev eth0 parent 1:1 classid 1:18 htb rate 4mbit

Configuring the Firewall Rules for Limiting Peer-to-Peer Network Individually



Enter the router's Firewall menu and choose the option to configure Firewall rules. The placement of these commands is important! The use of these commands may require you to remove default configuration settings, insert rules into an existing configuration, or modify current packet marking configurations. For maximum effectiveness, these rules should be placed immediately below any rules that flush/clear existing firewall rules (commands that begin with 'iptables -F').

Enter the following commands in the router's Firewall configuration file:
#Restore any previous connection marks
iptables -t mangle -A PREROUTING -p tcp -j CONNMARK --restore-mark

#Do not remark any packets--Accept any packets already marked
iptables -t mangle -A PREROUTING -p tcp -m mark ! --mark 0 -j ACCEPT

#Mark KaZaa P2P traffic with a value of 1
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --kazaa -j MARK --set-mark 1

#Mark BitTorrent P2P traffic with a value of 2
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --bit -j MARK --set-mark 2

#Mark ALL packets belonging to KaZaa P2P connections marked above with a value of 1
iptables -t mangle -A PREROUTING -p tcp -m mark --mark 1 -j CONNMARK --save-mark

#Mark ALL packets belonging to BitTorrent P2P connections marked above with a value of 2
iptables -t mangle -A PREROUTING -p tcp -m mark --mark 2 -j CONNMARK --save-mark

#Associate marked KaZaa packets transmitted on Ethernet0 with traffic class number 1:17
iptables -t mangle -A POSTROUTING -o eth0 -m mark --mark 1 -j CLASSIFY --set-class 1:17

#Associate marked BitTorrent packets transmitted on Ethernet0 with traffic class number 1:18
iptables -t mangle -A POSTROUTING -o eth0 -m mark --mark 2 -j CLASSIFY --set-class 1:18
Technical Support
Home >
Technical Notes >
Limiting P2P Traffic

Software Versions

General Availability
(GA) Releases


Envoy: 4.4.1-30
Others: 4.4.1-30
IDCA:

ICNA Certification


Get Your
ImageStream
Certification