diff options
Diffstat (limited to 'contrib/ipfilter/man/ipnat.5')
| -rw-r--r-- | contrib/ipfilter/man/ipnat.5 | 911 |
1 files changed, 672 insertions, 239 deletions
diff --git a/contrib/ipfilter/man/ipnat.5 b/contrib/ipfilter/man/ipnat.5 index 6d3f9bc..69163fc 100644 --- a/contrib/ipfilter/man/ipnat.5 +++ b/contrib/ipfilter/man/ipnat.5 @@ -2,159 +2,671 @@ .\" .TH IPNAT 5 .SH NAME -ipnat, ipnat.conf \- IP NAT file format +ipnat, ipnat.conf \- IPFilter 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 +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. -.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 +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 -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 +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 -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: +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 +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 +.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 -map de0 10.1.0.0/16 -> 201.2.3.4/32 + +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 -or as +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 -map de0 from 10.1.0.0/16 to any -> 201.2.3.4/32 + +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 -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. +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 +Divert rules can be be used with both inbound and outbound packet +matching however the rule +.B must +specify host addresses for the outer packet, not ranges of addresses +or netmasks, just single addresses. +Additionally the syntax must supply required information for UDP. +An example of what a divert rule looks ike is as follows: +.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. +.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 COMMON OPTIONS +This section deals with options that are available with all rules. +.TP +.B purge +When the purge keyword is added to the end of a NAT rule, it will +cause all of the active NAT sessions to be removed when the rule +is removed as an individual operation. If all of the NAT rules +are flushed out, it is expected that the operator will similarly +flush the NAT table and thus NAT sessions are not removed when the +NAT rules are flushed out. +.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 IPv6 +.PP +In all of the examples above, where an IPv4 address is present, an IPv6 +address can also be used. All rules must use either IPv4 addresses with +both halves of the NAT rule or IPv6 addresses for both halves. Mixing +IPv6 addresses with IPv4 addresses, in a single rule, will result in an +error. +.PP +For shorthand notations such as "0/32", the equivalent for IPv6 is +"0/128". IPFilter will treat any netmask greater than 32 as an +implicit direction that the address should be IPv6, not IPv4. +To be unambiguous with 0/0, for IPv6 use ::0/0. .SH KERNEL PROXIES .PP IP Filter comes with a few, simple, proxies built into the code that is loaded @@ -177,117 +689,38 @@ Mature - well tested, protocol is properly understood by the proxy; .PP The currently compiled in proxy list is as follows: -.HP +.TP FTP - Mature -.HP +(map ... proxy port ftp ftp/tcp) +.TP IRC - Experimental -.HP +(proxy port 6667 irc/tcp) +.TP rpcbind - Experimental -.HP +.TP +PPTP - Experimental +.TP H.323 - Experimental -.HP +(map ... proxy port 1720 h323/tcp) +.TP Real Audio (PNA) - Aging -.HP +.TP +DNS - Developmental +(map ... proxy port 53 dns/udp { block .cnn.com; }) +.TP IPsec - Developmental -.HP +(map ... proxy port 500 ipsec/tcp) +.TP netbios - Experimental -.HP +.TP 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. +(map ... proxy port shell rcmd/tcp) +.SH KERNEL PROXIES +.SH FILES /dev/ipnat .br +/etc/protocols +.br /etc/services .br /etc/hosts |
