1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
.\" $OpenBSD: ipnat.5,v 1.15 2000/04/26 21:04:00 deraadt Exp $
.\"
.TH IPNAT 5
.SH NAME
ipnat \- IP NAT file format
.SH DESCRIPTION
The format for files accepted by ipnat is described by the following grammar:
.LP
.nf
ipmap :: = mapblock | redir | map .
map ::= mapit ifname ipmask "->" ipmask [ mapport ] .
mapblock ::= "map-block" ifname ipmask "->" ipmask [ ports ] .
redir ::= "rdr" ifname [ fromspec ] ipmask "->" ip [ ports ] [ tcpudp ] .
ports ::= "ports" numports | "auto" .
mapit ::= "map" | "bimap" .
ipmask ::= ip "/" bits | ip "/" mask | ip "netmask" mask .
mapport ::= "portmap" tcpudp portnumber ":" portnumber .
fromspec ::= "from" ip "/" ipmask .
tcpudp ::= "tcp" | "udp" | "tcp/udp" .
portnumber ::= number { numbers } | "auto" .
ifname ::= 'A' - 'Z' { 'A' - 'Z' } numbers .
numbers ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' .
.fi
.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.
.PP
Packets which will be rewritten can only be selected by matching the original
source address. A netmask must be specified with the IP address.
.PP
The address selected for replacing the original is chosen from an IP#/netmask
pair. A netmask of all 1's indicating a hostname is valid. A netmask of
31 1's (255.255.255.254) is considered invalid as there is no space for
allocating host IP#'s after consideration for broadcast and network
addresses.
.PP
When remapping TCP and UDP packets, it is also possible to change the source
port number. Either TCP or UDP or both can be selected by each rule, with a
range of port numbers to remap into given as \fBport-number:port-number\fP.
.SH COMMANDS
There are four commands recognised by IP Filter's NAT code:
.TP
.B map
that is used for mapping one address or network to another in an unregulated
round robin fashion;
.TP
.B rdr
that is used for redirecting packets to one IP address and port pair to
another;
.TP
.B bimap
for setting up bidirectional NAT between an external IP address and an internal
IP address and
.TP
.B map-block
which sets up static IP address based translation, based on a algorithm to
squeeze the addresses to be translated into the destination range.
.SH MATCHING
.PP
For basic NAT and redirection of packets, the address subject to change is used
along with its protocol to check if a packet should be altered. In the case
of redirects, it is also possible to select packets on a source address basis
using the \fBfrom\fP keyword, as well as the manditory destination port. The
packet \fImatching\fP part of the rule is to the left of the "->" in each rule.
.SH TRANSLATION
.PP
To the right of the "->" is the address and port specificaton which will be
written into the packet providing it has already successful matched the
prior constraints. The case of redirections (\fBrdr\fP) is the simpliest:
the new destination address is that specified in the rule. For \fBmap\fP
rules, the destination address will be one for which the tuple combining
the new source and destination is known to be unique. If the packet is
either a TCP or UDP packet, the destination and source ports come into the
equation too. If the tuple already exists, IP Filter will increment the
port number first, within the available range specified with \fBportmap\fP
and if there exists no unique tuple, the source address will be incremented
within the specified netmask. If a unique tuple cannot be determined, then
the packet will not be translated. The \fBmap-block\fP is more limited in
how it searches for a new, free and unique tuple, in that it will used an
algorithm to determine what the new source address should be, along with the
range of available ports - the IP address is never changed and nor does the
port number ever exceed its alloted range.
.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.
.SH TRNSPARENT PROXIES
.PP
True transparent proxying should be performed using the redirect (\fBrdr\fP)
rules directing ports to localhost (127.0.0.1) with the proxy program doing
a lookup through \fB/dev/ipnat\fP to determine the real source and address
of the connection.
.SH EXAMPLES
.PP
This section deals with the \fBmap\fP command and it's variations.
.PP
To change IP#'s used internally from network 10 into an ISP provided 8 bit
subnet at 209.1.2.0 through the ppp0 interface, the following would be used:
.LP
.nf
map ppp0 10.0.0.0/8 -> 209.1.2.0/24
.fi
.PP
The obvious problem here is we're trying to squeeze over 16,000,000 IP
addresses into a 254 address space. To increase the scope, remapping for TCP
and/or UDP, port remapping can be used;
.LP
.nf
map ppp0 10.0.0.0/8 -> 209.1.2.0/24 portmap tcp/udp 1025:65000
.fi
.PP
which falls only 527,566 `addresses' short of the space available in network
10. If we were to combine these rules, they would need to be specified as
follows:
.LP
.nf
map ppp0 10.0.0.0/8 -> 209.1.2.0/24 portmap tcp/udp 1025:65000
map ppp0 10.0.0.0/8 -> 209.1.2.0/24
.fi
.PP
so that all TCP/UDP packets were port mapped and only other protocols, such as
ICMP, only have their IP# changed. In some instaces, it is more appropriate
to use the keyword \fBauto\fP in place of an actual range of port numbers if
you want to guarantee simultaneous access to all within the given range.
However, in the above case, it would default to 1 port per IP address, since
we need to squeeze 24 bits of address space into 8. A good example of how
this is used might be:
.LP
.nf
map ppp0 172.192.0.0/16 -> 209.1.2.0/24 portmap tcp/udp auto
.fi
.PP
which would result in each IP address being given a small range of ports to
use (252). The problem here is that the \fBmap\fP directive tells the NAT
code to use the next address/port pair available for an outgoing connection,
resulting in no easily discernable relation between external addresses/ports
and internal ones. This is overcome by using \fBmap-block\fP as follows:
.LP
.nf
map-block ppp0 172.192.0.0/16 -> 209.1.2.0/24 ports auto
.fi
.PP
For example, this 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.
/dev/ipnat
.br
/etc/services
.br
/etc/hosts
.SH SEE ALSO
ipnat(4), hosts(5), ipf(5), services(5), ipf(8), ipnat(8)
|
