diff options
Diffstat (limited to 'man/ipnat.5')
| -rw-r--r-- | man/ipnat.5 | 293 |
1 files changed, 293 insertions, 0 deletions
diff --git a/man/ipnat.5 b/man/ipnat.5 new file mode 100644 index 0000000..2d76a46 --- /dev/null +++ b/man/ipnat.5 @@ -0,0 +1,293 @@ +.TH IPNAT 5 +.SH NAME +ipnat, ipnat.conf \- 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 lhs "->" dstipmask [ mapicmp | mapport | mapproxy ] + mapoptions . +mapblock ::= "map-block" ifname lhs "->" ipmask [ ports ] mapoptions . +redir ::= "rdr" ifname rlhs "->" ip [ "," ip ] rdrport rdroptions . + +lhs ::= ipmask | fromto . +rlhs ::= ipmask dport | fromto . +dport ::= "port" portnum [ "-" portnum ] . +ports ::= "ports" numports | "auto" . +rdrport ::= "port" portnum . +mapit ::= "map" | "bimap" . +fromto ::= "from" object "to" object . +ipmask ::= ip "/" bits | ip "/" mask | ip "netmask" mask . +dstipmask ::= ipmask | "range" ip "-" ip . +mapicmp ::= "icmpidmap" "icmp" number ":" number . +mapport ::= "portmap" tcpudp portspec . +mapoptions ::= [ tcpudp ] [ "frag" ] [ age ] [ clamp ] . +rdroptions ::= rdrproto [ rr ] [ "frag" ] [ age ] [ clamp ] [ rdrproxy ] . + +object :: = addr [ port-comp | port-range ] . +addr :: = "any" | nummask | host-name [ "mask" ipaddr | "mask" hexnumber ] . +port-comp :: = "port" compare port-num . +port-range :: = "port" port-num range port-num . +rdrproto ::= tcpudp | protocol . + +rr ::= "round-robin" . +age ::= "age" decnumber [ "/" decnumber ] . +clamp ::= "mssclamp" decnumber . +tcpudp ::= "tcp/udp" | protocol . +mapproxy ::= "proxy" "port" port proxy-name '/' protocol +rdrproxy ::= "proxy" proxy-name . + +protocol ::= protocol-name | decnumber . +nummask ::= host-name [ "/" decnumber ] . +portspec ::= "auto" | portnumber ":" portnumber . +port ::= portnumber | port-name . +portnumber ::= number { numbers } . +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. The packet +\fImatching\fP part of the rule is to the left of the "->" in each rule. +.PP +Matching of packets has now been extended to allow more complex compares. +In place of the address which is to be translated, an IP address and port +number comparison can be made using the same expressions available with +\fBipf\fP. A simple NAT rule could be written as: +.LP +.nf +map de0 10.1.0.0/16 -> 201.2.3.4/32 +.fi +.LP +or as +.LP +.nf +map de0 from 10.1.0.0/16 to any -> 201.2.3.4/32 +.fi +.LP +Only IP address and port numbers can be compared against. This is available +with all NAT rules. +.SH TRANSLATION +.PP +To the right of the "->" is the address and port specification which will be +written into the packet providing it has already successfully matched the +prior constraints. The case of redirections (\fBrdr\fP) is the simplest: +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 allotted range. +.SH ICMPIDMAP +.PP +ICMP messages can be divided into two groups: "errors" and "queries". ICMP +errors are generated as a response of another IP packet. IP Filter will take +care that ICMP errors that are the response of a NAT-ed IP packet are +handled properly. +.PP +For 4 types of ICMP queries (echo request, timestamp request, information +request and address mask request) IP Filter supports an additional mapping +called "ICMP id mapping". All these 4 types of ICMP queries use a unique +identifier called the ICMP id. This id is set by the process sending the +ICMP query and it is usually equal to the process id. The receiver of the +ICMP query will use the same id in its response, thus enabling the +sender to recognize that the incoming ICMP reply is intended for him and is +an answer to a query that he made. The "ICMP id mapping" feature modifies +these ICMP id in a way identical to \fBportmap\fP for TCP or UDP. +.PP +The reason that you might want this, is that using this feature you don't +need an IP address per host behind the NAT box, that wants to do ICMP queries. +The two numbers behind the \fBicmpidmap\fP keyword are the first and the +last icmp id number that can be used. There is one important caveat: if you +map to an IP address that belongs to the NAT box itself (notably if you have +only a single public IP address), then you must ensure that the NAT box does +not use the \fBicmpidmap\fP range that you specified in the \fBmap\fP rule. +Since the ICMP id is usually the process id, it is wise to restrict the +largest permittable process id (PID) on your operating system to e.g. 63999 and +use the range 64000:65535 for ICMP id mapping. Changing the maximal PID is +system dependent. For most BSD derived systems can be done by changing +PID_MAX in /usr/include/sys/proc.h and then rebuild the system. +.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: +.HP +FTP - Mature +.HP +IRC - Experimental +.HP +rpcbind - Experimental +.HP +H.323 - Experimental +.HP +Real Audio (PNA) - Aging +.HP +IPsec - Developmental +.HP +netbios - Experimental +.HP +R-command - Mature + +.SH TRANSPARENT 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 LOAD-BALANCING +.PP +Two options for use with \fBrdr\fP are available to support primitive, +\fIround-robin\fP based load balancing. The first option allows for a +\fBrdr\fP to specify a second destination, as follows: +.LP +.nf +rdr le0 203.1.2.3/32 port 80 -> 203.1.2.3,203.1.2.4 port 80 tcp +.fi +.LP +This would send alternate connections to either 203.1.2.3 or 203.1.2.4. +In scenarios where the load is being spread amongst a larger set of +servers, you can use: +.LP +.nf +rdr le0 203.1.2.3/32 port 80 -> 203.1.2.3,203.1.2.4 port 80 tcp round-robin +rdr le0 203.1.2.3/32 port 80 -> 203.1.2.5 port 80 tcp round-robin +.fi +.LP +In this case, a connection will be redirected to 203.1.2.3, then 203.1.2.4 +and then 203.1.2.5 before going back to 203.1.2.3. In accomplishing this, +the rule is removed from the top of the list and added to the end, +automatically, as required. This will not effect the display of rules +using "ipnat -l", only the internal application order. +.SH EXAMPLES +.PP +This section deals with the \fBmap\fP command and its 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 instances, 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). In all cases, the new port number that is used is deterministic. +That is, port X will always map to port Y. +WARNING: It is not advisable to use the \fBauto\fP feature if you are map'ing +to a /32 (i.e. 0/32) because the NAT code will try to map multiple hosts to +the same port number, outgoing and ultimately this will only succeed for one +of them. +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 discernible 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) |
