man/ipnat.5

.TH IPNAT 5
.SH NAME
ipnat, ipnat.conf \- IPFilter NAT file format
.SH DESCRIPTION
.PP
The
.B ipnat.conf
file is used to specify rules for the Network Address Translation (NAT)
component of IPFilter.  To load rules specified in the
.B ipnat.conf
file, the
.B ipnat(8)
program is used.
.PP
For standard NAT functionality, a rule should start with \fBmap\fP and then
proceeds to specify the interface for which outgoing packets will have their
source address rewritten.  Following this it is expected that the old source
address, and optionally port number, will be specified.
.PP
In general, all NAT rules conform to the following layout:
the first word indicates what type of NAT rule is present, this is followed
by some stanzas to match a packet, followed by a "->" and this is then
followed by several more stanzas describing the new data to be put in the
packet.
.PP
In this text and in others,
use of the term "left hand side" (LHS) when talking about a NAT rule refers
to text that appears before the "->" and the "right hand side" (RHS) for text
that appears after it.  In essence, the LHS is the packet matching and the
RHS is the new data to be used.
.SH VARIABLES
.PP
This configuration file, like all others used with IPFilter, supports the
use of variable substitution throughout the text.
.nf

nif="ppp0";
map $nif 0/0 -> 0/32
.fi
.PP
would become
.nf

map ppp0 0/0 -> 0/32
.fi
.PP
Variables can be used recursively, such as 'foo="$bar baz";', so long as
$bar exists when the parser reaches the assignment for foo.
.PP
See
.B ipnat(8)
for instructions on how to define variables to be used from a shell
environment.
.SH OUTBOUND SOURCE TRANSLATION (map'ing)
Changing the source address of a packet is traditionally performed using
.B map
rules.  Both the source address and optionally port number can be changed
according to various controls.
.PP
To start out with, a common rule used is of the form:
.nf

map le0 0/0 -> 0/32
.fi
.PP
Here we're saying change the source address of all packets going out of
le0 (the address/mask pair of 0/0 matching all packets) to that of the
interface le0 (0/32 is a synonym for the interface's own address at
the current point in time.)  If we wanted to pass the packet through
with no change in address, we would write it as:
.nf

map le0 0/0 -> 0/0
.fi
.PP
If we only want to change a portion of our internal network and to a
different address that is routed back through this host, we might do:
.nf

map le0 10.1.1.0/24 -> 192.168.55.3/32
.fi
.PP
In some instances, we may have an entire subnet to map internal addresses
out onto, in which case we can express the translation as this:
.nf

map le0 10.0.0.0/8 -> 192.168.55.0/24
.fi
.PP
IPFilter will cycle through each of the 256 addresses in the 192.168.55.0/24
address space to ensure that they all get used.
.PP
Of course this poses a problem for TCP and UDP, with many connections made,
each with its own port number pair.  If we're unlucky, translations can be
dropped because the new address/port pair mapping already exists.  To
mitigate this problem, we add in port translation or port mapping:
.nf

map le0 10.0.0.0/8 -> 192.168.55.0/24 portmap tcp/udp auto
.fi
.PP
In this instance, the word "auto" tells IPFilter to calculate a private
range of port numbers for each address on the LHS to use without fear
of them being trampled by others.  This can lead to problems if there are
connections being generated mire quickly than IPFilter can expire them.
In this instance, and if we want to get away from a private range of
port numbers, we can say:
.nf

map le0 10.0.0.0/8 -> 192.168.55.0/24 portmap tcp/udp 5000:65000
.fi
.PP
And now each connection through le0 will add to the enumeration of
the port number space 5000-65000 as well as the IP address subnet
of 192.168.55.0/24.
.PP
If the new addresses to be used are in a consecutive range, rather
than a complete subnet, we can express this as:
.nf

map le0 10.0.0.0/8 -> range 192.168.55.10-192.168.55.249
                      portmap tcp/udp 5000:65000
.fi
.PP
This tells IPFilter that it has a range of 240 IP address to use, from
192.168.55.10 to 192.168.55.249, inclusive.
.PP
If there were several ranges of addresses for use, we can use each one
in a round-robin fashion as followed:
.nf

map le0 10.0.0.0/8 -> range 192.168.55.10-192.168.55.29
                      portmap tcp/udp 5000:65000 round-robin
map le0 10.0.0.0/8 -> range 192.168.55.40-192.168.55.49
                      portmap tcp/udp 5000:65000 round-robin
.fi
.PP
To specify translation rules that impact a specific IP protocol,
the protocol name or number is appended to the rule like this:
.nf

map le0 10.0.0.0/8 -> 192.168.55.0/24 tcp/udp
map le0 10.0.0.0/8 -> 192.168.55.1/32 icmp
map le0 10.0.0.0/8 -> 192.168.55.2/32 gre
.fi
.PP
For TCP connections exiting a connection such as PPPoE where the MTU is
slightly smaller than normal ethernet, it can be useful to reduce the
Maximum Segment Size (MSS) offered by the internal machines to match,
reducing the liklihood that the either end will attempt to send packets
that are too big and result in fragmentation.  This is acheived using the
.B mssclamp
option with TCP
.B map
rules like this:
.nf

map pppoe0 0/0 -> 0/32 mssclamp 1400 tcp
.fi
.PP
For ICMP packets, we can map the ICMP id space in query packets:
.nf

map le0 10.0.0.0/8 -> 192.168.55.1/32 icmpidmap icmp 1000:20000
.fi
.PP
If we wish to be more specific about our initial matching criteria on the
LHS, we can expand to using a syntax more similar to that in
.B ipf.conf(5)
:
.nf

map le0 from 10.0.0.0/8 to 26.0.0.0/8 ->
                      192.168.55.1
map le0 from 10.0.0.0/8 port > 1024 to 26.0.0.0/8 ->
                      192.168.55.2 portmap 5000:9999 tcp/udp
map le0 from 10.0.0.0/8 ! to 26.0.0.0/8 ->
                      192.168.55.3 portmap 5000:9999 tcp/udp
.fi
.TP
.B NOTE:
negation matching with source addresses is
.B NOT
possible with
.B map
/
.B map-block
rules.
.PP
The NAT code has builtin default timeouts for TCP, UDP, ICMP and another
for all other protocols.  In general, the timeout for an entry to be
deleted shrinks once a reply packet has been seen (excluding TCP.)
If you wish to specify your own timeouts, this can be achieved either
by setting one timeout for both directions:
.nf

map le0 0/0 -> 0/32 gre age 30
.fi
.PP
or setting a different timeout for the reply:
.nf

map le0 from any to any port = 53 -> 0/32 age 60/10 udp
.fi
.PP
A pressing problem that many people encounter when using NAT is that the
address protocol can be embedded inside an application's communication.
To address this problem, IPFilter provides a number of built-in proxies
for the more common trouble makers, such as FTP.  These proxies can be
used as follows:
.nf

map le0 0/0 -> 0/32 proxy port 21 ftp/tcp
.fi
.PP
In this rule, the word "proxy" tells us that we want to connect up this
translation with an internal proxy.  The "port 21" is an extra restriction
that requires the destination port number to be 21 if this rule is to be
activated.  The word "ftp" is the proxy identifier that the kernel will
try and resolve internally, "tcp" the protocol that packets must match.
.PP
See below for a list of proxies and their relative staus.
.PP
To associate NAT rules with filtering rules, it is possible to set and
match tags during either inbound or outbound processing.  At present the
tags for forwarded packets are not preserved by forwarding, so once the
packet leaves IPFilter, the tag is forgotten.  For
.B map
rules, we can match tags set by filter rules like this:
.nf

map le0 0/0 -> 0/32 proxy portmap 5000:5999 tag lan1 tcp
.fi
.PP
This would be used with "pass out" rules that includes a stanza such
as "set-tag (nat = lan1)".
.PP
If the interface in which packets are received is different from the
interface on which packets are sent out, then the translation rule needs
to be written to take this into account:
.nf

map hme0,le0 0/0 -> 0/32
.fi
.PP
Although this might seem counterintuitive, the interfaces when listed
in rules for
.B ipnat.conf
are always in the
.I inbound
,
.I outbound
order.  In this case, hme0 would be the return interface and le0 would be
the outgoing interface.  If you wish to allow return packets on any
interface, the correct syntax to use would be:
.nf

map *,le0 0/0 -> 0/32
.fi
.LP
A special variant of
.B map
rules exists, called
.B map-block.
This command is intended for use when there is a large network to be mapped
onto a smaller network, where the difference in netmasks is upto 14 bits
difference in size.  This is achieved by dividing the address space and
port space up to ensure that each source address has its own private range
of ports to use.  For example, this rule:
.nf

map-block ppp0 172.192.0.0/16 -> 209.1.2.0/24 ports auto
.fi
.PP
would result in 172.192.0.0/24 being mapped to 209.1.2.0/32
with each address, from 172.192.0.0 to 172.192.0.255 having 252 ports of its
own.  As opposed to the above use of \fBmap\fP, if for some reason the user
of (say) 172.192.0.2 wanted 260 simultaneous connections going out, they would
be limited to 252 with \fBmap-block\fP but would just \fImove on\fP to the next
IP address with the \fBmap\fP command.
.SS Extended matching
.PP
If it is desirable to match on both the source and destination of a packet
before applying an address translation to it, this can be achieved by using
the same from-to syntax as is used in \fBipf.conf\fP(5).  What follows
applies equally to the
.B map
rules discussed above and
.B rdr
rules discussed below.  A simple example is as follows:
.nf

map bge0 from 10.1.0.0/16 to 192.168.1.0/24 -> 172.12.1.4
.fi
.PP
This would only match packets that are coming from hosts that have a source
address matching 10.1.0.0/16 and a destination matching 192.168.1.0/24.
This can be expanded upon with ports for TCP like this:
.nf

rdr bge0 from 10.1.0.0/16 to any port = 25 -> 127.0.0.1 port 2501 tcp
.fi
.PP
Where only TCP packets from 10.1.0.0/16 to port 25 will be redirected to
port 2501.
.PP
As with \fBipf.conf\fR(5), if we have a large set of networks or addresses
that we would like to match up with then we can define a pool using
\fBippool\fR(8) in \fBippool.conf\fR(5) and then refer to it in an
\fBipnat\fR rule like this:
.nf

map bge0 from pool/100 to any port = 25 -> 127.0.0.1 port 2501 tcp
.fi
.TP
.B NOTE:
In this situation, the rule is considered to have a netmask of "0" and
thus is looked at last, after any rules with /16's or /24's in them,
.I even if
the defined pool only has /24's or /32's.  Pools may also be used
.I wherever
the from-to syntax in \fBipnat.conf\fR(5) is allowed.
.SH INBOUND DESTINATION TRANSLATION (redirection)
.PP
Redirection of packets is used to change the destination fields in a packet
and is supported for packets that are moving \fIin\fP on a network interface.
While the same general syntax for
.B map
rules is supported, there are differences and limitations.
.PP
Firstly, by default all redirection rules target a single IP address, not
a network or range of network addresses, so a rule written like this:
.nf

rdr le0 0/0 -> 192.168.1.0
.fi
.PP
Will not spread packets across all 256 IP addresses in that class C network.
If you were to try a rule like this:
.nf

rdr le0 0/0 -> 192.168.1.0/24
.fi
.PP
then you will receive a parsing error.
.PP
.PP
The from-to source-destination matching used with
.B map
rules can be used with rdr rules, along with negation, however the
restriction moves - only a source address match can be negated:
.nf

rdr le0 from 1.1.0.0/16 to any -> 192.168.1.3
rdr le0 ! from 1.1.0.0/16 to any -> 192.168.1.4
.fi
.PP
If there is a consective set of addresses you wish to spread the packets
over, then this can be done in one of two ways, the word "range" optional
to preserve:
.nf

rdr le0 0/0 -> 192.168.1.1 - 192.168.1.5
rdr le0 0/0 -> range 192.168.1.1 - 192.168.1.5
.fi
.PP
If there are only two addresses to split the packets across, the
recommended method is to use a comma (",") like this:
.nf

rdr le0 0/0 -> 192.168.1.1,192.168.1.2
.fi
.fi
.PP
If there is a large group of destination addresses that are somewhat
disjoint in nature, we can cycle through them using a
.B round-robin
technique like this:
.nf

rdr le0 0/0 -> 192.168.1.1,192.168.1.2 round-robin
rdr le0 0/0 -> 192.168.1.5,192.168.1.7 round-robin
rdr le0 0/0 -> 192.168.1.9 round-robin
.fi
.PP
If there are a large number of redirect rules and hosts being targetted
then it may be desirable to have all those from a single source address
be targetted at the same destination address.  To achieve this, the
word
.B sticky
is appended to the rule like this:
.nf

rdr le0 0/0 -> 192.168.1.1,192.168.1.2 sticky
rdr le0 0/0 -> 192.168.1.5,192.168.1.7 round-robin sticky
rdr le0 0/0 -> 192.168.1.9 round-robin sticky
.fi
.PP
The
.B sticky
feature can only be combined with
.B round-robin
and the use of comma.
.PP
For TCP and UDP packets, it is possible to both match on the destiantion
port number and to modify it.  For example, to change the destination port
from 80 to 3128, we would use a rule like this:
.nf

rdr de0 0/0 port 80 -> 127.0.0.1 port 3128 tcp
.fi
.PP
If a range of ports is given on the LHS and a single port is given on the
RHS, the entire range of ports is moved.  For example, if we had this:
.nf

rdr le0 0/0 port 80-88 -> 127.0.0.1 port 3128 tcp
.fi
.PP
then port 80 would become 3128, port 81 would become 3129, etc.  If we
want to redirect a number of different pots to just a single port, an
equals sign ("=") is placed before the port number on the RHS like this:
.nf

rdr le0 0/0 port 80-88 -> 127.0.0.1 port = 3128 tcp
.fi
.PP
In this case, port 80 goes to 3128, port 81 to 3128, etc.
.PP
As with
.B map
rules, it is possible to manually set a timeout using the
.B age
option, like this:
.nf

rdr le0 0/0 port 53 -> 127.0.0.1 port 10053 udp age 5/5
.fi
.PP
The use of proxies is not restricted to
.B map
rules and outbound sessions.  Proxies can also be used with redirect
rules, although the syntax is slightly different:
.nf

rdr ge0 0/0 port 21 -> 127.0.0.1 port 21 tcp proxy ftp
.fi
.PP
For
.B rdr
rules, the interfaces supplied are in the same order as
.B map
rules - input first, then output.  In situations where the outgoing interface
is not certain, it is also possible to use a wildcard ("*") to effect a match
on any interface.
.nf

rdr le0,* 0/0 -> 192.168.1.0
.fi
.PP
A single rule, with as many options set as possible would look something like
this:
.nf

rdr le0,ppp0 9.8.7.6/32 port 80 -> 1.1.1.1,1.1.1.2 port 80 tcp
    round-robin frag age 40/40 sticky mssclamp 1000 tag tagged
.fi
.SH REWRITING SOURCE AND DESTINATION
.PP
Whilst the above two commands provide a lot of flexibility in changing
addressing fields in packets, often it can be of benefit to translate
\fIboth\fP source \fBand\fR destination at the same time or to change
the source address on input or the destination address on output.
Doing all of these things can be accomplished using
.B rewrite
NAT rules.
.PP
A
.B rewrite
rule requires the same level of packet matching as before, protocol and
source/destination information but in addition allows either
.B in
or
.B out
to be specified like this:
.nf

rewrite in on ppp0 proto tcp from any to any port = 80 ->
	src 0/0 dst 127.0.0.1,3128;
rewrite out on ppp0 from any to any ->
	src 0/32 dst 10.1.1.0/24;
.fi
.PP
On the RHS we can specify both new source and destination information to place
into the packet being sent out.  As with other rules used in
\fBipnat.conf\fR, there are shortcuts syntaxes available to use the original
address information (\fB0/0\fR) and the address associated with the network
interface (\fB0/32\fR.)  For TCP and UDP, both address and port information
can be changed.  At present it is only possible to specify either a range of
port numbers to be used (\fBX-Y\fR) or a single port number (\fB= X\fR) as
follows:
.nf

rewrite in on le0 proto tcp from any to any port = 80 ->
	src 0/0,2000-20000 dst 127.0.0.1,port = 3128;
.fi
.PP
There are four fields that are stepped through in enumerating the number
space available for creating a new destination:
.LP
source address
.LP
source port
.LP
destination address
.LP
destination port
.PP
If one of these happens to be a static then it will be skipped and the next
one incremented.  As an example:
.nf

rewrite out on le0 proto tcp from any to any port = 80 ->
	src 1.0.0.0/8,5000-5999 dst 2.0.0.0/24,6000-6999;
.fi
.PP
The translated packets would be:
.LP
1st src=1.0.0.1,5000 dst=2.0.0.1,6000
.LP
2nd src=1.0.0.2,5000 dst=2.0.0.1,6000
.LP
3rd src=1.0.0.2,5001 dst=2.0.0.1,6000
.LP
4th src=1.0.0.2,5001 dst=2.0.0.2,6000
.LP
5th src=1.0.0.2,5001 dst=2.0.0.2,6001
.LP
6th src=1.0.0.3,5001 dst=2.0.0.2,6001
.PP
and so on.
.PP
As with
.B map
rules, it is possible to specify a range of addresses by including the word
\fIrange\fR before the addresses:
.nf

rewrite from any to any port = 80 ->
	src 1.1.2.3 - 1.1.2.6 dst 2.2.3.4 - 2.2.3.6;
.fi
.SH DIVERTING PACKETS
.PP
If you'd like to send packets to a UDP socket rather than just another
computer to be decapsulated, this can be achieved using a
.B divert
rule.
.PP
The syntax for these rules is much the same as
.B encap
rules, but instead the syntax must supply required information for UDP:
.nf

divert in on le0 proto udp from any to any port = 53 ->
	src 192.1.1.1,54 dst 192.168.1.22.1,5300;
.fi
.PP
On the LHS is a normal set of matching capabilities but on the RHS it is
a requirement to specify both the source and destination addresses and
ports.
.PP
As this feature is intended to be used with targetting packets at sockets
and not IPFilter running on other systems, there is no rule provided to
\fIundivert\fR packets.
.TP
.B NOTE:
Diverted packets \fImay\fP be fragmented if the addition of the
encapsulating IP header plus UDP header causes the packet to exceed
the size allowed by the outbound network interface.  At present it is
not possible to cause Path MTU discovery to happen as this feature
is intended to be transparent to both endpoints.
.SH ENCAPSULATING PACKETS
.PP
In addition to translating address fields of a packet, the NAT module in
IPFILter also supports wrapping them up in another IP packet and sending
them off to a new destination.  Full compliance of this feature with
RFC 1853 and RFC 2003 is pending implementation of support for PMTU
discovery with it.
.PP
Encapsulation can be performed on both incoming and outgoing packets
but
.B must
specify host addresses for the outer packet, not ranges of addresses
or netmasks, just single addresses.
.PP
As with the
.B rewrite
rules, the LHS requires a from/to match and terminates with a
semi-colon (";").  An example of what these might look like are:
.nf

encap out on le0 from any to any -> src 10.1.1.1 dst 192.168.1.1;
.fi
.TP
.B Path MTU Discovery
If Path MTU discovery is being used and the "do not fragment" flag
is set in packets to be encapsulated, an ICMP error message will
be sent back to the sender if the new packet would need to be
fragmented.
.SH RULE ORDERING
.PP
.B NOTE:
Rules in
.B ipnat.conf
are read in sequentially as listed and loaded into the kernel in this
fashion
.B BUT
packet matching is done on \fBnetmask\fR, going from 32 down to 0.
If a rule uses
.B pool
or
.B hash
to reference a set of addresses or networks, the netmask value for
these fields is considered to be "0".
So if your
.B ipnat.conf
has the following rules:
.nf

rdr le0 192.0.0.0/8 port 80 -> 127.0.0.1 3132 tcp
rdr le0 192.2.0.0/16 port 80 -> 127.0.0.1 3131 tcp
rdr le0 from any to pool/100 port 80 -> 127.0.0.1 port 3130 tcp
rdr le0 192.2.2.0/24 port 80 -> 127.0.0.1 3129 tcp
rdr le0 192.2.2.1 port 80 -> 127.0.0.1 3128 tcp
.fi
.PP
then the rule with 192.2.2.1 will match \fBfirst\fR, regardless of where
it appears in the ordering of the above rules.  In fact, the order in
which they would be used to match a packet is:
.nf

rdr le0 192.2.2.1 port 80 -> 127.0.0.1 3128 tcp
rdr le0 192.2.2.0/24 port 80 -> 127.0.0.1 3129 tcp
rdr le0 192.2.0.0/16 port 80 -> 127.0.0.1 3131 tcp
rdr le0 192.0.0.0/8 port 80 -> 127.0.0.1 3132 tcp
rdr le0 from any to pool/100 port 80 -> 127.0.0.1 port 3130 tcp
.fi
.PP
where the first line is actually a /32.
.PP
If your
.B ipnat.conf
file has entries with matching target fields (source address for
.B map
rules and destination address for
.B rdr
rules), then the ordering in the
.B ipnat.conf
file does matter.  So if you had the following:
.nf

rdr le0 from 1.1.0.0/16 to 192.2.2.1 port 80 -> 127.0.0.1 3129 tcp
rdr le0 from 1.1.1.0/24 to 192.2.2.1 port 80 -> 127.0.0.1 3128 tcp
.fi
.PP
Then no packets will match the 2nd rule, they'll all match the first.
.SH KERNEL PROXIES
.PP
IP Filter comes with a few, simple, proxies built into the code that is loaded
into the kernel to allow secondary channels to be opened without forcing the
packets through a user program.  The current state of the proxies is listed
below, as one of three states:
.HP
Aging - protocol is roughly understood from
the time at which the proxy was written but it is not well tested or
maintained;
.HP
Developmental - basic functionality exists, works most of the time but
may be problematic in extended real use;
.HP
Experimental - rough support for the protocol at best, may or may not
work as testing has been at best sporadic, possible large scale changes
to the code in order to properly support the protocol.
.HP
Mature - well tested, protocol is properly
understood by the proxy;
.PP
The currently compiled in proxy list is as follows:
.TP
FTP - Mature
(map ... proxy port ftp ftp/tcp)
.TP
IRC - Experimental
(proxy port 6667 irc/tcp)
.TP
rpcbind - Experimental
.TP
PPTP - Experimental
.TP
H.323 - Experimental
(map ... proxy port 1720 h323/tcp)
.TP
Real Audio (PNA) - Aging
.TP
IPsec - Developmental
(map ... proxy port 500 ipsec/tcp)
.TP
netbios - Experimental
.TP
R-command - Mature
(map ... proxy port shell rcmd/tcp)
.SH FILES
/dev/ipnat
.br
/etc/protocols
.br
/etc/services
.br
/etc/hosts
.SH SEE ALSO
ipnat(4), hosts(5), ipf(5), services(5), ipf(8), ipnat(8)