blob: 0b945cb76313113b847c9c7bfefe2f2837cbb81e [file] [log] [blame]
Henrik Nordstromc2794132004-01-22 15:04:24 +00001.TH IPTABLES 8 "Mar 09, 2002" "" ""
2.\"
3.\" Man page written by Herve Eychenne <rv@wallfire.org> (May 1999)
4.\" It is based on ipchains page.
5.\" TODO: add a word for protocol helpers (FTP, IRC, SNMP-ALG)
6.\"
7.\" ipchains page by Paul ``Rusty'' Russell March 1997
8.\" Based on the original ipfwadm man page by Jos Vos <jos@xos.nl>
9.\"
10.\" This program is free software; you can redistribute it and/or modify
11.\" it under the terms of the GNU General Public License as published by
12.\" the Free Software Foundation; either version 2 of the License, or
13.\" (at your option) any later version.
14.\"
15.\" This program is distributed in the hope that it will be useful,
16.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
17.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
18.\" GNU General Public License for more details.
19.\"
20.\" You should have received a copy of the GNU General Public License
21.\" along with this program; if not, write to the Free Software
22.\" Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
23.\"
24.\"
25.SH NAME
26iptables \- administration tool for IPv4 packet filtering and NAT
27.SH SYNOPSIS
28.BR "iptables [-t table] -[AD] " "chain rule-specification [options]"
29.br
30.BR "iptables [-t table] -I " "chain [rulenum] rule-specification [options]"
31.br
32.BR "iptables [-t table] -R " "chain rulenum rule-specification [options]"
33.br
34.BR "iptables [-t table] -D " "chain rulenum [options]"
35.br
36.BR "iptables [-t table] -[LFZ] " "[chain] [options]"
37.br
38.BR "iptables [-t table] -N " "chain"
39.br
40.BR "iptables [-t table] -X " "[chain]"
41.br
42.BR "iptables [-t table] -P " "chain target [options]"
43.br
44.BR "iptables [-t table] -E " "old-chain-name new-chain-name"
45.SH DESCRIPTION
46.B Iptables
47is used to set up, maintain, and inspect the tables of IP packet
48filter rules in the Linux kernel. Several different tables
49may be defined. Each table contains a number of built-in
50chains and may also contain user-defined chains.
51
52Each chain is a list of rules which can match a set of packets. Each
53rule specifies what to do with a packet that matches. This is called
54a `target', which may be a jump to a user-defined chain in the same
55table.
56
57.SH TARGETS
Jan Engelhardt6cf172e2008-03-10 17:48:59 +010058A firewall rule specifies criteria for a packet and a target. If the
Henrik Nordstromc2794132004-01-22 15:04:24 +000059packet does not match, the next rule in the chain is the examined; if
60it does match, then the next rule is specified by the value of the
61target, which can be the name of a user-defined chain or one of the
62special values
63.IR ACCEPT ,
64.IR DROP ,
65.IR QUEUE ,
66or
67.IR RETURN .
68.PP
69.I ACCEPT
70means to let the packet through.
71.I DROP
72means to drop the packet on the floor.
73.I QUEUE
Harald Welte7bdfca42005-07-28 15:24:02 +000074means to pass the packet to userspace. (How the packet can be received
75by a userspace process differs by the particular queue handler. 2.4.x
76and 2.6.x kernels up to 2.6.13 include the
77.B
78ip_queue
79queue handler. Kernels 2.6.14 and later additionally include the
80.B
81nfnetlink_queue
82queue handler. Packets with a target of QUEUE will be sent to queue number '0'
83in this case. Please also see the
84.B
85NFQUEUE
86target as described later in this man page.)
Henrik Nordstromc2794132004-01-22 15:04:24 +000087.I RETURN
88means stop traversing this chain and resume at the next rule in the
89previous (calling) chain. If the end of a built-in chain is reached
90or a rule in a built-in chain with target
91.I RETURN
92is matched, the target specified by the chain policy determines the
93fate of the packet.
94.SH TABLES
95There are currently three independent tables (which tables are present
96at any time depends on the kernel configuration options and which
97modules are present).
98.TP
99.BI "-t, --table " "table"
100This option specifies the packet matching table which the command
101should operate on. If the kernel is configured with automatic module
102loading, an attempt will be made to load the appropriate module for
103that table if it is not already there.
104
105The tables are as follows:
106.RS
107.TP .4i
108.BR "filter" :
109This is the default table (if no -t option is passed). It contains
110the built-in chains
111.B INPUT
Martin Josefsson2b9d07b2005-02-01 15:22:20 +0000112(for packets destined to local sockets),
Henrik Nordstromc2794132004-01-22 15:04:24 +0000113.B FORWARD
114(for packets being routed through the box), and
115.B OUTPUT
116(for locally-generated packets).
117.TP
118.BR "nat" :
119This table is consulted when a packet that creates a new
120connection is encountered. It consists of three built-ins:
121.B PREROUTING
122(for altering packets as soon as they come in),
123.B OUTPUT
124(for altering locally-generated packets before routing), and
125.B POSTROUTING
126(for altering packets as they are about to go out).
127.TP
128.BR "mangle" :
129This table is used for specialized packet alteration. Until kernel
1302.4.17 it had two built-in chains:
131.B PREROUTING
132(for altering incoming packets before routing) and
133.B OUTPUT
134(for altering locally-generated packets before routing).
135Since kernel 2.4.18, three other built-in chains are also supported:
136.B INPUT
137(for packets coming into the box itself),
138.B FORWARD
139(for altering packets being routed through the box), and
140.B POSTROUTING
141(for altering packets as they are about to go out).
Harald Weltea1885992004-10-06 12:32:54 +0000142.TP
143.BR "raw" :
144This table is used mainly for configuring exemptions from connection
145tracking in combination with the NOTRACK target. It registers at the netfilter
146hooks with higher priority and is thus called before ip_conntrack, or any other
147IP tables. It provides the following built-in chains:
148.B PREROUTING
149(for packets arriving via any network interface)
150.B OUTPUT
151(for packets generated by local processes)
Henrik Nordstromc2794132004-01-22 15:04:24 +0000152.RE
153.SH OPTIONS
154The options that are recognized by
155.B iptables
156can be divided into several different groups.
157.SS COMMANDS
Jan Engelhardt6cf172e2008-03-10 17:48:59 +0100158These options specify the desired action to perform. Only one of them
159can be specified on the command line unless otherwise stated
160below. For long versions of the command and option names, you
Henrik Nordstromc2794132004-01-22 15:04:24 +0000161need to use only enough letters to ensure that
162.B iptables
163can differentiate it from all other options.
164.TP
165.BI "-A, --append " "chain rule-specification"
166Append one or more rules to the end of the selected chain.
167When the source and/or destination names resolve to more than one
168address, a rule will be added for each possible address combination.
169.TP
170.BI "-D, --delete " "chain rule-specification"
171.ns
172.TP
173.BI "-D, --delete " "chain rulenum"
174Delete one or more rules from the selected chain. There are two
175versions of this command: the rule can be specified as a number in the
176chain (starting at 1 for the first rule) or a rule to match.
177.TP
178.BR "-I, --insert " "\fIchain\fP [\fIrulenum\fP] \fIrule-specification\fP"
179Insert one or more rules in the selected chain as the given rule
180number. So, if the rule number is 1, the rule or rules are inserted
181at the head of the chain. This is also the default if no rule number
182is specified.
183.TP
184.BI "-R, --replace " "chain rulenum rule-specification"
185Replace a rule in the selected chain. If the source and/or
186destination names resolve to multiple addresses, the command will
187fail. Rules are numbered starting at 1.
188.TP
189.BR "-L, --list " "[\fIchain\fP]"
190List all rules in the selected chain. If no chain is selected, all
Jan Engelhardt6cf172e2008-03-10 17:48:59 +0100191chains are listed. Like every other iptables command, it applies to the
Henrik Nordstromc2794132004-01-22 15:04:24 +0000192specified table (filter is the default), so NAT rules get listed by
193.nf
194 iptables -t nat -n -L
195.fi
196Please note that it is often used with the
197.B -n
198option, in order to avoid long reverse DNS lookups.
199It is legal to specify the
200.B -Z
201(zero) option as well, in which case the chain(s) will be atomically
202listed and zeroed. The exact output is affected by the other
203arguments given. The exact rules are suppressed until you use
204.nf
205 iptables -L -v
206.fi
207.TP
Henrik Nordstrom96296cf2008-05-13 13:08:26 +0200208.BR "-S, --list-rules " "[\fIchain\fP]"
209Print all rules in the selected chain. If no chain is selected, all
210chains are printed like iptables-save. Like every other iptables command,
211it applies to the specified table (filter is the default).
212.TP
Henrik Nordstromc2794132004-01-22 15:04:24 +0000213.BR "-F, --flush " "[\fIchain\fP]"
214Flush the selected chain (all the chains in the table if none is given).
215This is equivalent to deleting all the rules one by one.
216.TP
217.BR "-Z, --zero " "[\fIchain\fP]"
218Zero the packet and byte counters in all chains. It is legal to
219specify the
220.B "-L, --list"
221(list) option as well, to see the counters immediately before they are
222cleared. (See above.)
223.TP
224.BI "-N, --new-chain " "chain"
225Create a new user-defined chain by the given name. There must be no
226target of that name already.
227.TP
228.BR "-X, --delete-chain " "[\fIchain\fP]"
229Delete the optional user-defined chain specified. There must be no references
Harald Welte3a026932005-11-22 22:22:28 +0000230to the chain. If there are, you must delete or replace the referring rules
231before the chain can be deleted. The chain must be empty, i.e. not contain
232any rules. If no argument is given, it will attempt to delete every
233non-builtin chain in the table.
Henrik Nordstromc2794132004-01-22 15:04:24 +0000234.TP
235.BI "-P, --policy " "chain target"
236Set the policy for the chain to the given target. See the section
237.B TARGETS
238for the legal targets. Only built-in (non-user-defined) chains can have
239policies, and neither built-in nor user-defined chains can be policy
240targets.
241.TP
242.BI "-E, --rename-chain " "old-chain new-chain"
243Rename the user specified chain to the user supplied name. This is
244cosmetic, and has no effect on the structure of the table.
245.TP
246.B -h
247Help.
248Give a (currently very brief) description of the command syntax.
249.SS PARAMETERS
250The following parameters make up a rule specification (as used in the
251add, delete, insert, replace and append commands).
252.TP
253.BR "-p, --protocol " "[!] \fIprotocol\fP"
254The protocol of the rule or of the packet to check.
255The specified protocol can be one of
256.IR tcp ,
257.IR udp ,
258.IR icmp ,
259or
260.IR all ,
261or it can be a numeric value, representing one of these protocols or a
262different one. A protocol name from /etc/protocols is also allowed.
263A "!" argument before the protocol inverts the
264test. The number zero is equivalent to
265.IR all .
266Protocol
267.I all
268will match with all protocols and is taken as default when this
269option is omitted.
270.TP
271.BR "-s, --source " "[!] \fIaddress\fP[/\fImask\fP]"
272Source specification.
273.I Address
274can be either a network name, a hostname (please note that specifying
275any name to be resolved with a remote query such as DNS is a really bad idea),
276a network IP address (with /mask), or a plain IP address.
277The
278.I mask
279can be either a network mask or a plain number,
280specifying the number of 1's at the left side of the network mask.
281Thus, a mask of
282.I 24
283is equivalent to
284.IR 255.255.255.0 .
285A "!" argument before the address specification inverts the sense of
286the address. The flag
287.B --src
288is an alias for this option.
289.TP
290.BR "-d, --destination " "[!] \fIaddress\fP[/\fImask\fP]"
291Destination specification.
292See the description of the
293.B -s
294(source) flag for a detailed description of the syntax. The flag
295.B --dst
296is an alias for this option.
297.TP
298.BI "-j, --jump " "target"
299This specifies the target of the rule; i.e., what to do if the packet
300matches it. The target can be a user-defined chain (other than the
301one this rule is in), one of the special builtin targets which decide
302the fate of the packet immediately, or an extension (see
303.B EXTENSIONS
304below). If this
Henrik Nordstrom17fc1632005-11-05 09:26:40 +0000305option is omitted in a rule (and
306.B -g
307is not used), then matching the rule will have no
Henrik Nordstromc2794132004-01-22 15:04:24 +0000308effect on the packet's fate, but the counters on the rule will be
309incremented.
310.TP
Henrik Nordstrom17fc1632005-11-05 09:26:40 +0000311.BI "-g, --goto " "chain"
312This specifies that the processing should continue in a user
313specified chain. Unlike the --jump option return will not continue
314processing in this chain but instead in the chain that called us via
315--jump.
316.TP
Henrik Nordstromc2794132004-01-22 15:04:24 +0000317.BR "-i, --in-interface " "[!] \fIname\fP"
Matthew Strait403cf6a2004-03-17 14:26:08 +0000318Name of an interface via which a packet was received (only for
Henrik Nordstromc2794132004-01-22 15:04:24 +0000319packets entering the
320.BR INPUT ,
321.B FORWARD
322and
323.B PREROUTING
324chains). When the "!" argument is used before the interface name, the
325sense is inverted. If the interface name ends in a "+", then any
326interface which begins with this name will match. If this option is
327omitted, any interface name will match.
328.TP
329.BR "-o, --out-interface " "[!] \fIname\fP"
330Name of an interface via which a packet is going to be sent (for packets
331entering the
332.BR FORWARD ,
333.B OUTPUT
334and
335.B POSTROUTING
336chains). When the "!" argument is used before the interface name, the
337sense is inverted. If the interface name ends in a "+", then any
338interface which begins with this name will match. If this option is
339omitted, any interface name will match.
340.TP
341.B "[!] " "-f, --fragment"
342This means that the rule only refers to second and further fragments
343of fragmented packets. Since there is no way to tell the source or
344destination ports of such a packet (or ICMP type), such a packet will
345not match any rules which specify them. When the "!" argument
346precedes the "-f" flag, the rule will only match head fragments, or
347unfragmented packets.
348.TP
349.BI "-c, --set-counters " "PKTS BYTES"
350This enables the administrator to initialize the packet and byte
351counters of a rule (during
352.B INSERT,
353.B APPEND,
354.B REPLACE
355operations).
356.SS "OTHER OPTIONS"
357The following additional options can be specified:
358.TP
359.B "-v, --verbose"
360Verbose output. This option makes the list command show the interface
361name, the rule options (if any), and the TOS masks. The packet and
362byte counters are also listed, with the suffix 'K', 'M' or 'G' for
3631000, 1,000,000 and 1,000,000,000 multipliers respectively (but see
364the
365.B -x
366flag to change this).
367For appending, insertion, deletion and replacement, this causes
368detailed information on the rule or rules to be printed.
369.TP
370.B "-n, --numeric"
371Numeric output.
372IP addresses and port numbers will be printed in numeric format.
373By default, the program will try to display them as host names,
374network names, or services (whenever applicable).
375.TP
376.B "-x, --exact"
377Expand numbers.
378Display the exact value of the packet and byte counters,
379instead of only the rounded number in K's (multiples of 1000)
380M's (multiples of 1000K) or G's (multiples of 1000M). This option is
381only relevant for the
382.B -L
383command.
384.TP
385.B "--line-numbers"
386When listing rules, add line numbers to the beginning of each rule,
387corresponding to that rule's position in the chain.
388.TP
389.B "--modprobe=command"
390When adding or inserting rules into a chain, use
391.B command
392to load any necessary modules (targets, match extensions, etc).
393.SH MATCH EXTENSIONS
394iptables can use extended packet matching modules. These are loaded
395in two ways: implicitly, when
396.B -p
397or
398.B --protocol
399is specified, or with the
400.B -m
401or
402.B --match
403options, followed by the matching module name; after these, various
404extra command line options become available, depending on the specific
405module. You can specify multiple extended match modules in one line,
406and you can use the
407.B -h
408or
409.B --help
410options after the module has been specified to receive help specific
411to that module.
412
413The following are included in the base package, and most of these can
414be preceded by a
415.B !
416to invert the sense of the match.
417.\" @MATCH@
418.SH TARGET EXTENSIONS
419iptables can use extended target modules: the following are included
420in the standard distribution.
421.\" @TARGET@
422.SH DIAGNOSTICS
423Various error messages are printed to standard error. The exit code
424is 0 for correct functioning. Errors which appear to be caused by
425invalid or abused command line parameters cause an exit code of 2, and
426other errors cause an exit code of 1.
427.SH BUGS
428Bugs? What's this? ;-)
Harald Welte64d900f2005-06-24 16:37:00 +0000429Well, you might want to have a look at http://bugzilla.netfilter.org/
Henrik Nordstromc2794132004-01-22 15:04:24 +0000430.SH COMPATIBILITY WITH IPCHAINS
431This
432.B iptables
433is very similar to ipchains by Rusty Russell. The main difference is
434that the chains
435.B INPUT
436and
437.B OUTPUT
438are only traversed for packets coming into the local host and
439originating from the local host respectively. Hence every packet only
440passes through one of the three chains (except loopback traffic, which
441involves both INPUT and OUTPUT chains); previously a forwarded packet
442would pass through all three.
443.PP
444The other main difference is that
445.B -i
446refers to the input interface;
447.B -o
448refers to the output interface, and both are available for packets
449entering the
450.B FORWARD
451chain.
452.PP The various forms of NAT have been separated out;
453.B iptables
454is a pure packet filter when using the default `filter' table, with
455optional extension modules. This should simplify much of the previous
456confusion over the combination of IP masquerading and packet filtering
457seen previously. So the following options are handled differently:
458.nf
459 -j MASQ
460 -M -S
461 -M -L
462.fi
463There are several other changes in iptables.
464.SH SEE ALSO
465.BR iptables-save (8),
466.BR iptables-restore (8),
467.BR ip6tables (8),
468.BR ip6tables-save (8),
Harald Welte7bdfca42005-07-28 15:24:02 +0000469.BR ip6tables-restore (8),
470.BR libipq (3).
Henrik Nordstromc2794132004-01-22 15:04:24 +0000471.P
472The packet-filtering-HOWTO details iptables usage for
473packet filtering, the NAT-HOWTO details NAT,
474the netfilter-extensions-HOWTO details the extensions that are
475not in the standard distribution,
476and the netfilter-hacking-HOWTO details the netfilter internals.
477.br
478See
479.BR "http://www.netfilter.org/" .
480.SH AUTHORS
Harald Welte7bdfca42005-07-28 15:24:02 +0000481Rusty Russell originally wrote iptables, in early consultation with Michael
Henrik Nordstromc2794132004-01-22 15:04:24 +0000482Neuling.
483.PP
484Marc Boucher made Rusty abandon ipnatctl by lobbying for a generic packet
485selection framework in iptables, then wrote the mangle table, the owner match,
486the mark stuff, and ran around doing cool stuff everywhere.
487.PP
488James Morris wrote the TOS target, and tos match.
489.PP
490Jozsef Kadlecsik wrote the REJECT target.
491.PP
Harald Welte7bdfca42005-07-28 15:24:02 +0000492Harald Welte wrote the ULOG and NFQUEUE target, the new libiptc, as well as the TTL, DSCP, ECN matches and targets.
Henrik Nordstromc2794132004-01-22 15:04:24 +0000493.PP
Patrick McHardy110a89a2007-01-28 01:24:55 +0000494The Netfilter Core Team is: Marc Boucher, Martin Josefsson, Yasuyuki Kozakai,
Yasuyuki KOZAKAIe605d762007-02-15 06:41:58 +0000495Jozsef Kadlecsik, Patrick McHardy, James Morris, Pablo Neira Ayuso,
496Harald Welte and Rusty Russell.
Henrik Nordstromc2794132004-01-22 15:04:24 +0000497.PP
Harald Welte7bdfca42005-07-28 15:24:02 +0000498Man page originally written by Herve Eychenne <rv@wallfire.org>.
Henrik Nordstromc2794132004-01-22 15:04:24 +0000499.\" .. and did I mention that we are incredibly cool people?
500.\" .. sexy, too ..
501.\" .. witty, charming, powerful ..
502.\" .. and most of all, modest ..