This article explains in brief what Packet Mangling is, what fields of IP packet header can be modified using iptables, and how packets are matched against the chains of rules in the netfilter mangle table.
The term "mangling" might mislead people to conceive it as malicious—packet mangling is nothing like that at all. Packet mangling refers to the process of intentionally altering data in IP packet headers before or after the routing process.
Let's recall what an IP packet header looks like:
Mangling of packets is done only with NAT and is a part of the NAT process. In NAT, we can "mangle" a packet as modifying the Source IP address and Destination IP address fields of the IP header.
So, using the mangle table of netfilter we can modify the following two fields:
TOS: the 8 bit Type Of Service field
TTL: the 8 bit Time to live field
iptables can also set a mark to IP packets that can be used internal by iproute2 for source routing and/or QoS with tc. This internal mark, called nfmark (netfilter mark), doesn't alter any of the IP packet headers' fields. Nfmarks can be set using the MARK target in iptables, which has three options that we can see using --help in conjunction with the MARK target:
root@router:~# iptables -j MARK --help
… some lines missing…
MARK target v1.3.1 options:
--set-mark value Set nfmark value
--and-mark value Binary AND the nfmark with value
--or-mark value Binary OR the nfmark with value
Example: mark packets to 192.168.1.100 with nfmark 6:
iptables -t mangle -A POSTROUTING -d 192.168.1.100 -j MARK --set-mark 6
The TOS field is 8 bits long and was discussed in the previous chapter. Alteration of the TOS field is very useful for QoS. For this, iptables uses TOS target that has the --set-tos option. We can see TOS target options using --help in the command line:
root@router:~# iptables -j TOS --help
… some lines missing…
TOS target v1.3.5 options:
--set-tos value Set Type of Service field to one of the
following numeric or descriptive values:
Minimize-Delay 16 (0x10)
Maximize-Throughput 8 (0x08)
Maximize-Reliability 4 (0x04)
Minimize-Cost 2 (0x02)
Normal-Service 0 (0x00)
Example: set TOS to Maximize-Throughput for outgoing FTP data:
iptables -t mangle -A POSTROUTING -p tcp --sport 20 -j TOS --set-tos 8
There are only five TOS values we can set; so the TOS target doesn't modify the whole TOS byte. However, this can be done with DSCP (Differentiated Services Field Codepoints). The DSCP bits are the first six bits in the TOS byte, like in the following figure:
iptables has the DSCP target that can be used to alter the DSCP bits. The options can be found using --help with the DSCP target.
root@router:~# iptables -j DSCP --help
… some lines missing…
DSCP target options
--set-dscp value Set DSCP field in packet header to value
This value can be in decimal (ex: 32)
or in hex (ex: 0x20)
--set-dscp-class class Set the DSCP field in packet header
to the value represented by the DiffServ class
This class may be EF,BE or any of the CSxx
or AFxx classes.
These two options are mutually exclusive !
Example: set DSCP 32 to packets arriving on interface Eth0:
iptables -t mangle -A PREROUTING -i eth0 -j DSCP --set-dscp 32
DSCP is explained in more detail in RFC2474, which can be found at http://www.rfc-editor.org/rfc/rfc2474.txt.
The TTL field of the IP packet header is the Time To Live for that IP packet, and can be altered using the TTL target of iptables.
root@router:~# iptables -j TTL --help
… some lines missing…
TTL target v1.3.1 options
--ttl-set value Set TTL to
--ttl-dec value Decrement TTL by
--ttl-inc value Increment TTL by
Altering TTL can be useful, for example, if you want a client not to distribute Internet to others. If you set the TTL value to 1 for packets going to a certain IP address, then only the device having that IP address receives IP packets. If the packet is destined to a host behind that IP address, the TTL will be decremented and the IP packet will be dropped.
Example: set TTL to 1 for packets going out interface ppp0:
iptables -t mangle -I POSTROUTING -o ppp0 -j TTL --ttl-set 1
The netfilter mangle Table
The mangle table has five chains, named PREROUTING, INPUT, FORWARD, OUTPUT, and POSTROUTING. Let's look again at the packet flow diagram again:
The rules in PREROUTING chain of the mangle table are analyzed by the kernel when a packet comes in, before the routing process takes place.
If the packet is not for the router (is destined to a host behind it), the kernel looks up the rules in the mangle table FORWARD chain and afterwards the mangle table POSTROUTING chain.
If the packet is destined to the router, then the mangle table INPUT chain is analyzed. When the response is generated, the kernel looks up the rules in the OUTPUT chain of the mangle table, and last the POSTROUTING chain of the mangle table.
On those chains, all iptables operations are possible.
It is not recommended to perform packet filtering in the mangle table. Even if you are not restricted to drop packets in the mangle table, it should be only for rules that mangle IP packets.
A particularity of the mangle table is that, unlike the filter or nat tables, all rules are analyzed, even if a packet is matched against one rule. This functionality of the mangle table was needed, because you might want to alter the same IP packet in more ways (set DSCP, nfmark, and TTL at the same time), and so, unlike the other tables, if a match is found against one rule in a chain, the kernel doesn't stop there, and tries to match the packet against all the other rules in that chain.
This is one of the major reasons for which packet filtering in the mangle table is strongly discouraged.
This article has been extracted from the book, Designing and Implementing Linux Firewalls and QoS using netfilter, iproute2, NAT and l7-filter.
For further details please visit: http://www.packtpub.com/firewall/book
Lucian Gheorghe has just joined the Global NOC of Interoute, Europe's largest voice and data network provider. Before Interoute, he was working as a senior network engineer for Globtel Internet, a significant Internet and Telephony Services Provider to the Romanian market He has been working with Linux for more than 8 years putting a strong accent on security for protecting vital data from hackers and ensuring good quality services for internet customers. Moving to VoIP services he had to focus even more on security as sensitive billing data is most often stored on servers with public IP addresses. He has been studying QoS implementations on Linux to build different types of services for IP customers and also to deliver good quality for them and for VoIP over the public internet. Lucian has also been programming with Perl, PHP and Smarty for over 5 years mostly developing in-house management interfaces for IP and VoIP services.