Home > Articles

This chapter is from the book

This chapter is from the book

iptables Syntax

As presented earlier, iptables uses the concept of separate rule tables for different packet processing functionality. Nondefault tables are specified by a command-line option. Three tables are available:

  • filter—The filter table is the default table. It contains the actual firewall filtering rules. The built-in chains include these:

    • INPUT

    • OUTPUT


  • nat—The nat table contains the rules for Source and Destination Address and Port Translation. These rules are functionally distinct from the firewall filter rules. The built-in chains include these:




  • mangle—The mangle table contains rules for setting specialized packet-routing flags. These flags are then inspected later by rules in the filter table. The built-in chains include these:

    • PREROUTING (routed packets)

    • INPUT (packets arriving at the firewall but after the PREROUTING chain)

    • FORWARD (changes packets being routed through the firewall)

    • POSTROUTING (changes packets just before they leave the firewall, after the OUTPUT chain)

    • OUTPUT (locally generated packets)

Table 3.1 Conventions Representing Command-Line Syntax Options




A bar or pipe symbol separates alternate syntax options. For example, most of the iptables commands have both a short and a long form, such as -L and --list, and so they would be listed as alternate options because you would use one or the other of -L or --list.


Angle brackets indicate a user-supplied value, such as a string or numeric value.

[ ]

Square brackets indicate that the enclosed command, option, or value is optional. For example, most match operators can take a negation operator, !, which matches anything other than the value specified in the match. The negation operator is usually placed between the match operator and the value to be matched.


A colon indicates a range of values. The two values define the minimum and maximum values within the range. Because ranges themselves are optional, the convention is more often presented as <value>[:<value>].

filter Table Commands

The filter table commands are provided by the ip_tables module. The functionality is enabled by loading the module, which is done automatically with the first invocation of the iptables command, or it could be compiled into the kernel itself, which means you don’t need to worry about modules being loaded at all.

filter Table Operations on Entire Chains

Table 3.2 shows the iptables operations on entire chains.

Table 3.2 iptables Operations on Entire Chains



-N | --new-chain <chain>

Creates a user-defined chain.

-F | --flush [<chain>]

Flushes the chain, or all chains if none is specified.

-X | --delete-chain [<chain>]

Deletes the user-defined chain, or all chains if none is specified.

-P | --policy <chain> <policy>

Defines the default policy for one of the built-in chains, INPUT, OUTPUT, or FORWARD. The policy is either ACCEPT or DROP.

-L | --list [<chain>]

Lists the rules in the chain, or all chains if none is specified.

-Z | --zero

Resets the packet and byte counters associated with each chain.

-h | <some command> -h

Lists the iptables commands and options, or if preceded by an iptables command, lists the syntax and options for that command.


Use <command> to load the necessary module(s) when adding or inserting a rule into a chain.

-E | --rename-chain <old chain> <new chain>

Renames the user-defined chain <old chain> to the user-defined chain <new chain>.

The -h help command is obviously not an operation on a chain nor is --modprobe= <command>, but I didn’t know where else to list the command.

The list command takes additional options, as shown in Table 3.3.

Table 3.3 Options to the List Chain Command



-L -n | --numeric

Lists the IP addresses and port numbers numerically, rather than by name

-L -v | --verbose

Lists additional information about each rule, such as the byte and packet counters, rule options, and relevant network interface

-L -x | --exact

Lists the exact values of the counter, rather than the rounded-off values

-L -line-numbers

Lists the rule’s position within its chain

filter Table Operations on a Rule

The most frequently used commands to create or delete rules within a chain are shown in Table 3.4.

Table 3.4 Chain Commands on Individual Rules



-A | --append <chain>

Appends a rule to the end of a chain

-I | --insert <chain>

Inserts a rule at the beginning of the chain

-R | --replace <chain> <rule number> <rule specification>

Replaces a rule in the chain

-D | --delete <chain> <rule number>

Deletes the rule at position rule number within a chain

Basic filter Table Match Operations

The basic filter match operations supported in the default iptables filter table are listed in Table 3.5.

Table 3.5 filter Table Rule Operations



-i | --in-interface [!] [<interface>]

For incoming packets on either the INPUT or the FORWARD chains, or their user-defined subchains, specifies the interface name that the rule applies to. If no interface is specified, all interfaces are implied.

-o | --out-interface [!] [<interface>]

For outgoing packets on either the OUTPUT or the FORWARD chains, or their user-defined subchains, specifies the interface name that the rule applies to. If no interface is specified, all interfaces are implied.

-p | --protocol [!] [<protocol>]

Specifies the IP protocol that the rule applies to. The built-in protocols are tcp, udp, icmp, and all. The protocol value can be either the name or the numeric value, as listed in /etc/protocols.

-s | --source | --src [!] <address>[</mask>]

Specifies the host or network source address in the IP header.

-d | --destination | --dst [!] <address>[</mask>]

Specifies the host or network destination address in the IP header.

-j | --jump <target>

Specifies the target disposition for the packet if it matches the rule. The default targets include the built-in targets, an extension, or a user-defined chain.

[!] -f | --fragment

Specifies second and additional fragmented packets. The negated version of this specifies unfragmented packets.

-c | --set-counters <packets> <bytes>

Initializes the packet and byte counters.

tcp filter Table Match Operations

TCP header match options are listed in Table 3.6.

Table 3.6 tcp filter Table Match Operations

-p tcp Option


--source-port | --sport [[!] <port>[:<port>]]

This command specifies the source ports.

--destination-port | --dport [!] <port>[:<port>]

This command specifies the destination ports.

--tcp-flags [!] <mask>[,<mask>] <set>[,<set>]

This command tests the bits in the mask list, out of which the following bits must be set in order to match.

[!] -syn

The SYN flag must be set as an initial connection request.

--tcp-option [!] <number>

The only legal tcp option is the maximum packet size that the sending host is willing to accept.

udp filter Table Match Operations

UDP header match options are listed in Table 3.7.

Table 3.7 udp filter Table Match Operations

-p udp Option


--source-port | --sport [!] <port>[:<port>]

Specifies the source ports

--destination-port | --dport [!] <port>[:<port>]

Specifies the destination ports

icmp filter Table Match Operations

ICMP header match options are listed in Table 3.8.

Table 3.8 icmp filter Table Match Operations



--icmp-type [!] <type>

Specifies the ICMP type name or number. The ICMP type is used in place of a source port.

The major supported ICMP type names and numeric values are the following:

  • echo-reply (0)

  • destination-unreachable (3)

    • network-unreachable

    • host-unreachable

    • protocol-unreachable

    • port-unreachable

    • fragmentation-needed

    • network-unknown

    • host-unknown

    • network-prohibited

    • host-prohibited

  • source-quench (4)

  • redirect (5)

  • echo-request (8)

  • time-exceeded (10)

  • parameter-problem (11)

iptables -p icmp -h

filter Table Target Extensions

The filter table target extensions include logging functionality and the capability to reject a packet rather than dropping it.

Table 3.9 lists the options available to the LOG target. Table 3.10 lists the single option available to the REJECT target.

Table 3.9 LOG Target Extension

-j LOG Option


--log-level <syslog level>

Log level is either the numeric or the symbolic login priority, as listed in /usr/include/sys/syslog.h. These are the same log levels used in /etc/syslog.conf. The levels are emerg (0), alert (1), crit (2), err (3), warn (4), notice (5), info (6), memerg (0), alert (1), crit (2), err (3), warn (4), notice (5), info (6), and debut (7).

--log-prefix <"descriptive string">

The prefix is a quoted string that will be printed at the start of the log message for the rule.


This command includes any IP header options in the log output.


This command includes the TCP packet’s sequence number in the log output.


This command includes any TCP header options in the log output.

Table 3.10 REJECT Target Extension

-j REJECT Option


--reject-with <ICMP type 3>

By default, a rejected packet results in an ICMP type 3 icmp-port-unreachable message being returned to the sender. Other type 3 error messages can be returned instead, including icmp-net-unreachable, icmp-host-unreachable, icmp-proto-unreachable, icmp-net-prohibited, and icmp-host-prohibited.

--reject-with tcp-reset

Incoming TCP packets can be rejected with the more standard TCP RST message, rather than an ICMP error message.

--reject-with echo-reply

ping echo-request messages can be rejected with a faked echo-reply message. That is, the firewall generates the reply, but the request is not forwarded to the target host.

The ULOG Table Target Extension

Related to the LOG target is the ULOG target, which sends the log message to a userspace program for logging. Behind the scenes for ULOG, the packet gets multicast by the kernel through a netlink socket of your choosing (the default is socket 1). The userspace daemon would then read the message from the socket and do with it what it pleases. The ULOG target is typically used to provide more extensive logging than is possible with the standard LOG target.

As with the LOG target, processing continues after matches on a ULOG targeted rule. The ULOG target has four configuration options, as described in Table 3.11.

Table 3.11 ULOG Target Extension



--ulog-nlgroup <group>

Defines the netlink group that will receive the packet. The default group is 1.

--ulog-prefix <prefix>

Messages will be prefixed by this value, up to 32 characters in length.

--ulog-cprange <size>

The size in bytes to send to the netlink socket. The default is 0, which sends the entire packet.

--ulog-qthreshold <size>

The size in packets to queue within the kernel. The default is 1, which means that one packet is sent per message to the netlink socket.

filter Table Match Extensions

The filter table match extensions provide access to the fields in the TCP, UDP, and ICMP headers, as well as the match features available in iptables, such as maintaining connection state, port lists, access to the hardware MAC source address, and access to the IP TOS field.

multiport filter Table Match Extension

multiport port lists can include up to 15 ports per list. Whitespace isn’t allowed. There can be no blank spaces between the commas and the port values. Port ranges cannot be interspersed in the list. Also, the -m multiport command must exactly follow the -p <protocol> specifier.

Table 3.12 lists the options available to the multiport match extension.

Table 3.12 multiport Match Extension

m | --match multiport Option


--source-port <port> [,<port>]

Specifies the source port(s).

--destination-port <port> [,<port>]

Specifies the destination port(s).

--port <port>[,<port>]

Source and destination ports are equal, and they match a port in the list.

The multiport syntax can be a bit tricky. Some examples and cautions are included here. The following rule blocks incoming packets arriving on interface eth0 destined for the UDP ports associated with NetBIOS and SMB, common ports that are exploited on Microsoft Windows computers and targets for worms:

iptables -A INPUT -i eth0 -p udp\
     -m multiport --destination-port 135,136,137,138,139 -j DROP

The next rule blocks outgoing connection requests sent through the eth0 interface to high ports associated with the TCP services NFS, socks, and squid:

iptables -A OUTPUT -o eth0 -p tcp\
     -m multiport --destination-port 2049,1080,3128 --syn -j REJECT

What is important to note in this example is that the multiport command must exactly follow the protocol specification. A syntax error would have resulted if the --syn were placed between the -p tcp and the -m multiport.

To show a similar example of --syn placement, the following is correct:

iptables -A INPUT -i <interface> -p tcp \
     -m multiport --source-port 80,443 ! --syn -j ACCEPT

However, this causes a syntax error:

iptables -A INPUT -i <interface> -p tcp ! --syn \
     -m multiport --source-port 80,443 -j ACCEPT

Furthermore, the placement of source and destination parameters is not obvious. The following two variations are correct:

iptables -A INPUT -i <interface> -p tcp -m multiport \
     --source-port 80,443 \
     ! --syn -d $IPADDR --dport 1024:65535 -j ACCEPT


iptables -A INPUT -i <interface> -p tcp -m multiport \
     --source-port 80,443 \
     -d $IPADDR ! --syn --dport 1024:65535 -j ACCEPT

However, this causes a syntax error:

iptables -A INPUT -i <interface> -p tcp -m multiport \
     --source-port 80,443 \
     -d $IPADDR --dport 1024:65535 ! --syn -j ACCEPT

This module has some surprising syntax side effects. Either of the two preceding correct rules produces a syntax error if the reference to the SYN flag is removed:

iptables -A INPUT -i <interface> -p tcp -m multiport \
     --source-port 80,443 \
     -d $IPADDR --dport 1024:65535 -j ACCEPT

The following pair of rules, however, does not:

iptables -A OUTPUT -o <interface> \
    -p tcp -m multiport --destination-port 80,443 \
    ! --syn -s $IPADDR --sport 1024:65535 -j ACCEPT

iptables -A OUTPUT -o <interface> \
    -p tcp -m multiport --destination-port 80,443 \
    --syn -s $IPADDR --sport 1024:65535 -j ACCEPT

Note that the --destination-port argument to the multiport module is not the same as the --destination-port or --dport argument to the module that performs matching for the -p tcp arguments.

limit filter Table Match Extension

Rate-limited matching is useful for choking back the number of log messages that would be generated during a flood of logged packets.

Table 3.13 lists the options available to the limit match extension.

Table 3.13 limit Match Extension

-m | --match limit Option


--limit <rate>

Maximum number of packets to match within the given time frame

--limit-burst <number>

Maximum number of initial packets to match before applying the limit

The burst rate defines the number of initial matches to be accepted. The default value is five matches. When the limit has been reached, further matches are limited to the rate limit. The default limit is three matches per hour. Optional time frame specifiers include /second, /minute, /hour, and /day.

In other words, by default, when the initial burst rate of five matches is reached within the time limit, at most three more packets will match over the next hour, one every 20 minutes, regardless of how many packets are received. If a match doesn’t occur within the rate limit, the burst is recharged by one.

It’s easier to demonstrate rate-limited matching than it is to describe it in words. The following rule will limit logging of incoming ping message matches to one per second when an initial five echo-requests are received within a given second:

iptables -A INPUT -i eth0 \
     -p icmp --icmp-type echo-request \
     -m limit --limit 1/second -j LOG

It’s also possible to do rate-limited packet acceptance. The following two rules, in combination, will limit acceptance of incoming ping messages to one per second when an initial five echo-requests are received within a given second:

iptables -A INPUT -i eth0 \
     -p icmp --icmp-type echo-request \
     -m limit --limit 1/second -j ACCEPT

iptables -A INPUT -i eth0 \
     -p icmp --icmp-type echo-request -j DROP

The next rule limits the number of log messages generated in response to dropped ICMP redirect messages. When an initial five messages have been logged within a 20-minute time frame, at most three more log messages will be generated over the next hour, one every 20 minutes:

iptables -A INPUT -i eth0 \
     -p icmp --icmp-type redirect \
     -m limit -j LOG

The assumption in the final example is that the packet and any additional unmatched redirect packets are silently dropped by the default DROP policy for the INPUT chain.

dstlimit filter Table Match Extension

The dstlimit match extension enables rate limiting on a per-destination basis, whether per IP address or per port. Note the difference between the dstlimit match extension and the limit match extension, which has one limit for packets of a certain type.

Table 3.14 lists the options for the dstlimit match extension.

Table 3.14 dstlimit Match Extension



--dstlimit <average>

Maximum average match rate in packets per second.

--dstlimit-mode <mode>

Defines the limit to be per IP (dstip), per IP and port tuple (dstip-dstport), per source IP and destination IP tuple (srcip-dstip), or per source IP and destination IP and destination port tuple (srcipdstip-dstport).

--dstlimit-name <name>

Specifies the name for the file to be placed in /proc/net/ipt_dstlimit/.

[--dstlimit-burst <burst>]

Specifies the number of packets that should be matched when received as a burst of packets. The default is 5.

[--dstlimit-htable-size <size>]

Defines the number of buckets in the hashtable.

[--dstlimit-htable-max <entries>]

Defines the limit for the number of entries in the hashtable.

[--dstlimit-htable-gcinterval <interval>]

Defines the length of time between cleanup of the hashtable. The value for <interval> is in milliseconds, with the default being 1000 ms.

[--dstlimit-htable-expire <time>]

Defines the amount of time before an idle entry is purged from the hashtable. The value is in milliseconds, with the default being 10000 ms.

state filter Table Match Extension

Static filters look at traffic on a packet-by-packet basis alone. Each packet’s particular combination of source and destination addresses and ports, the transport protocol, and the current TCP state flag combination is examined without reference to any ongoing context. ICMP messages are treated as unrelated, out-of-band IP Layer 3 events.

The state extension provides additional monitoring and recording technology to augment the stateless, static packet-filter technology. State information is recorded when a TCP connection or UDP exchange is initiated. Subsequent packets are examined not only based on the static tuple information, but also within the context of the ongoing exchange. In other words, some of the contextual knowledge usually associated with the upper TCP Transport layer, or the UDP Application layer, is brought down to the filter layer.

After the exchange is initiated and accepted, subsequent packets are identified as part of the established exchange. Associated ICMP messages are identified as being related to a particular exchange.

(In computer terminology, a collection of values or attributes that together uniquely identify an event or object is called a tuple. A UDP or TCP packet is uniquely identified by the tuple combination of its protocol, UDP or TCP, the source and destination addresses, and the source and destination ports.)

For session monitoring, the advantages of maintaining state information are less obvious for TCP because TCP maintains state information by definition. For UDP, the immediate advantage is the capability to distinguish responses from other datagrams. In the case of an outgoing DNS request, which represents a new UDP exchange, the concept of an established session allows an incoming UDP response datagram from the host and port the original message was sent to, within a certain time-limited window. Incoming UDP datagrams from other hosts or ports are not allowed. They are not part of the established state for this particular exchange. When applied to TCP and UDP, ICMP error messages are accepted if the error message is related to the particular session.

In considering packet flow performance and firewall complexity, the advantages are more obvious for TCP flows. Flows are primarily a firewall performance and optimization technology. The main goal of flows is to allow bypassing the firewall inspection path for a packet. Much faster TCP packet handling is obtained in some cases because the remaining firewall filters can be skipped if the TCP packet is immediately recognized as part of an allowed, ongoing connection. For TCP connections, flow state can be a major win in terms of filtering performance. Also, standard TCP application protocol rules can be collapsed into a single initial allow rule. The number of filter rules is reduced (theoretically, but not necessarily in practice, as you’ll see later in the book).

The main disadvantage is that maintaining a state table requires more memory than standard firewall rules alone. Routers with 70,000 simultaneous connections, for example, would require tremendous amounts of memory to maintain state table entries for each connection. State maintenance is often done in hardware for performance reasons, where associative table lookups can be done simultaneously or in parallel. Whether implemented in hardware or software, state engines must be capable of reverting a packet to the traditional path if memory isn’t available for the state table entry.

Also, table creation, lookup, and teardown take time in software. The additional processing overhead is a loss in many cases. State maintenance is a win for ongoing exchanges such as an FTP transfer or a UDP streaming multimedia session. Both types of data flow represent potentially large numbers of packets (and filter rule match tests). State maintenance is not a firewall performance win for a simple DNS or NTP client/server exchange, however. State buildup and teardown can easily require as much processing—and more memory—than simply traversing the filter rules for these packets.

The advantages are also questionable for firewalls that filter primarily web traffic. Web client/server exchanges tend to be brief and ephemeral.

Telnet and SSH sessions are in a gray area. On heavily trafficked routers with many such sessions, the state maintenance overhead may be a win by bypassing the firewall inspection. For fairly quiescent sessions, however, it’s likely that the connection state entry will timeout and be thrown away. The state table entry will be re-created when the next packet comes along, after it has passed the traditional firewall rules.

Table 3.15 lists the options available to the state match extension.

Table 3.15 state Match Extension

-m | --match state Option


--state <state>[,<state>]

Matches if the connection state is one in the list. Legal values are NEW, ESTABLISHED, RELATED, or INVALID.

TCP connection state and ongoing UDP exchange information can be maintained, allowing network exchanges to be filtered as NEW, ESTABLISHED, RELATED, or INVALID:

  • NEW is equivalent to the initial TCP SYN request, or to the first UDP packet.

  • ESTABLISHED refers to the ongoing TCP ACK messages after the connection is initiated, to subsequent UDP datagrams exchanged between the same hosts and ports, and to ICMP echo-reply messages sent in response to a previous echo-request.

  • RELATED currently refers only to ICMP error messages. FTP secondary connections are managed by the additional FTP connection tracking support module. With the addition of that module, the meaning of RELATED is extended to include the secondary FTP connection.

  • An example of an INVALID packet is an incoming ICMP error message that wasn’t a response to a current session, or an echo-reply that wasn’t a response to a previous echo-request.

Ideally, using the ESTABLISHED match allows the firewall rule pair for a service to be collapsed into a single rule that allows the first request packet. For example, using the ESTABLISHED match, a web client rule requires allowing only the initial outgoing SYN request. A DNS client request requires only the rule allowing the initial UDP outgoing request packet.

With a deny-by-default input policy, connection tracking can be used (theoretically) to replace all protocol-specific filters with two general rules that allow incoming and outgoing packets that are part of an established connection, or packets related to the connection. Application-specific rules are required for the initial packet alone.

Although such a firewall setup might very well work for a small or residential site in most cases, it is unlikely to perform adequately for a larger site or a firewall that handles many connections simultaneously. The reason goes back to the case of state table entry timeouts, in which a state entry for a quiescent connection is replaced because of table size and memory constraints. The next packet that would have been accepted by the deleted state entry requires a rule to allow the packet, and the state table entry must be rebuilt.

A simple example of this is a rule pair for a local DNS server operating as a cache-and-forward name server. A DNS forwarding name server uses server-to-server communication. DNS traffic is exchanged between source and destination ports 53 on both hosts. The UDP client/server relationship can be made explicit. The following rules explicitly allow outgoing (NEW) requests, incoming (ESTABLISHED) responses, and any (RELATED) ICMP error messages:

iptables -A INPUT -m state \

iptables -A OUTPUT --out-interface <interface> -p udp \
     -s $IPADDR --source-port 53 -d $NAME_SERVER --destination-port 53 \
     -m state --state NEW,RELATED -j ACCEPT

DNS uses a simple query-and-response protocol. But what about an application that can maintain an ongoing connection for extended periods, such as an FTP control session or a telnet or SSH session? If the state table entry is cleared out prematurely for some reason, future packets won’t have a state entry to be matched against to be identified as part of an ESTABLISHED exchange.

The following rules for an SSH connection allow for that possibility:

iptables -A INPUT -m state \

iptables -A OUTPUT -m state \

iptables -A OUTPUT --out-interface <interface> -p tcp \
     -s $IPADDR --source-port $UNPRIVPORTS \
     -d $REMOTE_SSH_SERVER --destination-port 22 \
     -m state --state NEW, -j ACCEPT

iptables -A OUTPUT --out-interface <interface> -p tcp ! --syn \
     -s $IPADDR --source-port $UNPRIVPORTS \
     -d $REMOTE_SSH_SERVER --destination-port 22 \
     -j ACCEPT

iptables -A INPUT --in-interface <interface> -p tcp ! --syn \
     -s $REMOTE_SSH_SERVER --source-port 22 \
     -d $IPADDR --destination-port $UNPRIVPORTS \
     -j ACCEPT

mac filter Table Match Extension

Table 3.16 lists the options available to the mac match extension.

Table 3.16 mac Match Extension

-m | --match mac Option


--mac-source [!] <address>

Matches the Layer 2 Ethernet hardware source address, specified as xx:xx:xx:xx:xx:xx:, in the incoming Ethernet frame

Remember that MAC addresses do not cross router borders (or network segments). Also remember that only source addresses can be specified. The mac extension can be used only on an in-interface, such as the INPUT, PREROUTING, and FORWARD chains.

The following rule allows incoming SSH connections from a single local host:

iptables -A INPUT -i <local interface> -p tcp \
     -m mac --mac-source xx:xx:xx:xx:xx:xx \
     --source-port 1024:65535 \
     -d <IPADDR> --dport 22 -j ACCEPT

owner filter Table Match Extension

Table 3.17 lists the options available to the owner match extension.

Table 3.17 owner Match Extension

-m | --match owner Option


--uid-owner <userid>

Matches on the creator’s UID

--gid-owner <groupid>

Matches on the creator’s GID

--pid-owner <processid>

Matches on the creator’s PID

--sid-owner <sessionid>

Matches on the creator’s SID or PPID

--cmd-owner <name>

Matches on a packet created by a process with command name name

The match refers to the packet’s creator. The extension can be used on the OUTPUT chain only.

These match options don’t make much sense on a firewall router; they make more sense on an end host.

So, let’s say that you have a firewall gateway with a monitor, perhaps, but no keyboard. Administration is done from a local, multiuser host. A single user account is allowed to log in to the firewall from this host. On the multiuser host, administrative access to the firewall could be locally filtered as shown here:

iptables -A OUTPUT -o eth0 -p tcp \
     -s <IPADDR> --sport 1024:65535 \
     -d <fw IPADDR> --dport 22 \
     -m owner --uid-owner <admin userid> \
     --gid-owner <admin groupid> -j ACCEPT

mark filter Table Match Extension

Table 3.18 lists the options available to the mark match extension.

Table 3.18 mark Match Extension

-m | -match mark Option


--mark <value>[/<mask>]

Matches packets having the Netfilter-assigned mark value

The mark value and the mask are unsigned long values. If a mask is specified, the value and the mask are ANDed together.

In the example, assume that an incoming telnet client packet between a specific source and destination had been marked previously:

iptables -A FORWARD -i eth0 -o eth1 -p tcp \
     -s <some src address> --sport 1024:65535 \
     -d <some destination address> --dport 23 \
     -m mark --mark 0x00010070 \
     -j ACCEPT

The mark value being tested for here was set at some earlier point in the packet processing. The mark value is a flag indicating that this packet is to be handled differently from other packets.

tos filter Table Match Extension

Table 3.19 lists the options available to the tos match extension.

Table 3.19 tos Match Extension

-m | --match tos Option


--tos <value>

Matches on the IP TOS setting

The tos value can be one of either the string or numeric values:

  • minimize-delay, 16, 0x10

  • maximize-throughput, 8, 0x08

  • maximize-reliability, 4, 0x04

  • minimize-cost, 2, 0x02

  • normal-service, 0, 0x00

The TOS field has been redefined as the Differentiated Services (DS) field for use by the Differentiated Services Control Protocol (DSCP).

For more information on Differentiated Services, see these sources:

  • RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers"

  • RFC 2475, "An Architecture for Differentiated Services"

  • RFC 2990, "Next Steps for the IP QoS Architecture"

  • RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP"

  • RFC 3260, "New Terminology and Clarifications for Diffserv"

unclean filter Table Match Extension

The specific packet-validity checks performed by the unclean module are not documented. The module is considered to be experimental, and the iptables authors recommend against its use for now.

The following line shows the unclean module syntax. The module takes no arguments:

-m | --match unclean

The unclean extension might be "blessed" by the time this book is published. In the meantime, the module lends itself to an example of the LOG options:

iptables -A INPUT -p ! tcp -m unclean \
     -j LOG --log-prefix "UNCLEAN packet: " \

iptables -A INPUT -p tcp -m unclean \
     -j LOG --log-prefix "UNCLEAN TCP: " \
     --log-ip-options \
     --log-tcp-sequence --log-tcp-options

iptables -A INPUT -m unclean -j DROP

addrtype filter Table Match Extension

The addrtype match extension is used to match packets based on the type of address used, such as unicast, broadcast, and multicast. The types of addresses include those listed in Table 3.20.

Table 3.20 Address Types Used with the addrtype Match




An anycast packet


A blackhole address


A broadcast address


A local address


A multicast address


A prohibited address


A unicast address


An unreachable address


An unspecified address

Two commands are used with the addrtype match, as listed in Table 3.21.

Table 3.21 addrtype Match Commands



--src-type <type>

Matches for addresses with a source of type <type>.

--dst-type <type>

Matches for addresses with a destination of type <type>.

iprange filter Table Match

Sometimes defining a range of IP addresses using CIDR notation is insufficient for your needs. For example, if you need to limit a certain range of IPs that don’t fall on a subnet boundary or cross that boundary by only a couple addresses, the iprange match type will do the job.

Using the iprange match, you specify an arbitrary range of IP addresses for the match to take effect. The iprange match can also be negated. Table 3.22 lists the commands for the iprange match.

Table 3.22 iprange Match Commands



[!] --src-range <ip address-ip address>

Specifies (or negates) the range of IP addresses to match. The range is given with a single hyphen and no spaces.

[!] --dst-range <ip address-ip address>

Specifies (or negates) the range of IP addresses to match. The range is given with a single hyphen and no spaces.

length filter Table Match

The length filter table match examines the length of the packet. If the packet’s length matches the value given or optionally falls within the range given, the rule is invoked. Table 3.23 lists the one and only command related to the length match.

Table 3.23 length Match Command



--length <length>[:<length>]

Matches a packet of <length> or within the range <length:length>

NAT Table Target Extensions

As mentioned earlier, iptables supports four general kinds of NAT: source NAT (SNAT); destination NAT (DNAT); masquerading (MASQUERADE), which is a specialized case of the SNAT implementation; and local port direction (REDIRECT) to the local host. As part of the NAT table, each of these targets is available when a rule specifies the nat table by using the -t nat table specifier.

SNAT nat Table Target Extension

Source Address and Port Translation (NAPT) is the kind of NAT people are most commonly fmiliar with. As shown in a href="javascript:popUp(''/content/images/chap3_0672327716/elementLinks/03fig05.jpg'')">Figure 3.5, Source Address Translation is done after the routing decision is made. SNAT is a legal target only in the POSTROUTING chain. Because SNAT is applied immediately before the packet is sent out, only an outgoing interface can be specified./p>

a href="javascript:popUp(''/content/images/chap3_0672327716/elementLinks/03fig05.jpg'')">

a href="javascript:popUp(''/content/images/chap3_0672327716/elementLinks/03fig05.jpg'')">Figure 3.5 NAT packet traversal.

Some documents refer to this form of source NAT (the most common form) as NAPT, to acknowledge the port number modification. The other form of traditional, unidirectional NAT is basic NAT, which doesn’t touch the source port. That form is used when you are translating between the private LAN and a pool of public addresses.

NAPT is used when you have a single public address. The source port is changed to a free port on the firewall/NAT machine because it’s translating for any number of internal computers, and the port that the internal machine is using might already be in use by the NAT machine. When the responses come back, the port is all that the NAT machine has to determine that the packet is really meant for an internal computer rather than itself and then to determine which internal computer the packet is meant for.

The general syntax for SNAT is as follows:

iptables -t nat -A POSTROUTING --out-interface <interface> ... \
     -j SNAT --to-source <address>[-<address>][:<port>-<port>]

The source address can be mapped to a range of possible IP addresses, if more than one is available.

The source port can be mapped to a specific range of source ports on the router.

MASQUERADE nat Table Target Extension

Source Address Translation has been implemented in two different ways in iptables, as SNAT and as MASQUERADE. The difference is that the MASQUERADE target extension is intended for use with connections on interfaces with dynamically assigned IP addresses, particularly in the case in which the connection is temporary and the IP address assignment is likely to be different at each new connection. As discussed previously, in the section "NAT Table Features," MASQUERADE can be useful for phone dial-up connections in particular.

Because masquerading is a specialized case of SNAT, it is likewise a legal target only in the POSTROUTING chain, and the rule can refer to the outgoing interface only. Unlike the more generalized SNAT, MASQUERADE does not take an argument specifying the source address to apply to the packet. The IP address of the outgoing interface is used automatically.

The general syntax for MASQUERADE is as follows:

iptables -t nat -A POSTROUTING --out-interface <interface> ... \
     -j MASQUERADE [--to-ports <port>[-<port>]]

The source port can be mapped to a specific range of source ports on the router.

DNAT nat Table Target Extension

Destination Address and Port Translation is a highly specialized form of NAT. A residential or small business site is most likely to find this feature useful if its public IP address is dynamically assigned or if the site has a single IP address, and the site administrator wants to forward incoming connections to internal servers that aren’t publicly visible. In other words, the DNAT features can be used to replace the previously required third-party port-forwarding software, such as ipmasqadm.

Referring back to Figure 3.5, Destination Address and Port Translation is done before the routing decision is made. DNAT is a legal target in the PREROUTING and OUTPUT chains. On the PREROUTING chain, DNAT can be a target when the incoming interface is specified. On the OUTPUT chain, DNAT can be a target when the outgoing interface is specified.

The general syntax for DNAT is as follows:

iptables -t nat -A PREROUTING --in-interface <interface> ... \
     -j DNAT --to-destination <address>[-<address>][:<port>-<port>]
iptables -t nat -A OUTPUT --out-interface <interface> ... \
     -j DNAT --to-destination <address>[-<address>][:<port>-<port>]

The destination address can be mapped to a range of possible IP addresses, if more than one is available.

The destination port can be mapped to a specific range of alternate ports on the destination host.

REDIRECT nat Table Target Extension

Port redirection is a specialized case of DNAT. The packet is redirected to a port on the local host. Incoming packets that would otherwise be forwarded on are redirected to the incoming interface’s INPUT chain. Outgoing packets generated by the local host are redirected to a port on the local host’s loopback interface.

REDIRECT is simply an alias, a convenience, for the specialized case of redirecting a packet to this host. It offers no additional functional value. DNAT could just as easily be used to cause the same effect.

REDIRECT is likewise a legal target only in the PREROUTING and OUTPUT chains. On the PREROUTING chain, REDIRECT can be a target when the incoming interface is specified. On the OUTPUT chain, REDIRECT can be a target when the outgoing interface is specified.

The general syntax for REDIRECT is as follows:

iptables -t nat -A PREROUTING --in-interface <interface> ... \
     -j REDIRECT [--to-ports <port>[-<port>]]
iptables -t nat -A OUTPUT --out-interface <interface> ... \
     -j REDIRECT [--to-ports <port>[-<port>]]

The destination port can be mapped to a different port or to a specific range of alternate ports on the local host.

BALANCE nat Table Target Extension

The BALANCE target enables a round-robin method of sending connections to more than one target host. The BALANCE target uses a range of addresses for this purpose and thus provides a rudimentary load-balancing.

The general syntax for BALANCE is as follows:

iptables -t nat -A PREROUTING -p tcp -j BALANCE \
     --to-destination <ip address>-<ip address>

The CLUSTERIP target also provides some of these same options.

mangle Table Commands

The mangle table targets and extensions apply to the OUTPUT and PREROUTING chains. Remember, the filter table is implied by default. To use the mangle table features, you must specify the mangle table with the -t mangle directive.

mark mangle Table Target Extension

Table 3.24 lists the target extensions available to the mangle table.

Table 3.24 mangle Target Extensions

-t mangle Option


-j MARK --set-mark <value>

Sets the value of the Netfilter mark value for this packet

-j TOS --set-tos <value>

Sets the TOS value in the IP header

There are two mangle table target extensions: MARK and TOS. MARK contains the functionality to set the unsigned long mark value for the packet maintained by the iptables mangle table.

An example of usage follows:

iptables -t mangle -A PREROUTING --in-interface eth0 -p tcp \
     -s <some src address> --sport 1024:65535 \
     -d <some destination address> --dport 23 \
     -j MARK --set-mark 0x00010070

TOS contains the functionality to set the TOS bits in the IP header.

An example of usage follows:

iptables -t mangle -A OUTPUT ... -j TOS --set-tos <tos>

The possible tos values are the same values available in the filt

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020