| ipnat.5 (153881) | ipnat.5 (255332) |
|---|---|
| 1.\" $FreeBSD: head/contrib/ipfilter/man/ipnat.5 153881 2005-12-30 11:52:26Z guido $ | 1.\" $FreeBSD: head/contrib/ipfilter/man/ipnat.5 255332 2013-09-06 23:11:19Z cy $ |
| 2.\" 3.TH IPNAT 5 4.SH NAME | 2.\" 3.TH IPNAT 5 4.SH NAME |
| 5ipnat, ipnat.conf \- IP NAT file format | 5ipnat, ipnat.conf \- IPFilter NAT file format |
| 6.SH DESCRIPTION | 6.SH DESCRIPTION |
| 7The format for files accepted by ipnat is described by the following grammar: 8.LP | 7.PP 8The 9.B ipnat.conf 10file is used to specify rules for the Network Address Translation (NAT) 11component of IPFilter. To load rules specified in the 12.B ipnat.conf 13file, the 14.B ipnat(8) 15program is used. 16.PP 17For standard NAT functionality, a rule should start with \fBmap\fP and then 18proceeds to specify the interface for which outgoing packets will have their 19source address rewritten. Following this it is expected that the old source 20address, and optionally port number, will be specified. 21.PP 22In general, all NAT rules conform to the following layout: 23the first word indicates what type of NAT rule is present, this is followed 24by some stanzas to match a packet, followed by a "->" and this is then 25followed by several more stanzas describing the new data to be put in the 26packet. 27.PP 28In this text and in others, 29use of the term "left hand side" (LHS) when talking about a NAT rule refers 30to text that appears before the "->" and the "right hand side" (RHS) for text 31that appears after it. In essence, the LHS is the packet matching and the 32RHS is the new data to be used. 33.SH VARIABLES 34.PP 35This configuration file, like all others used with IPFilter, supports the 36use of variable substitution throughout the text. |
| 9.nf | 37.nf |
| 10ipmap :: = mapblock | redir | map . | |
| 11 | 38 |
| 12map ::= mapit ifname lhs "->" dstipmask [ mapicmp | mapport | mapproxy ] 13 mapoptions . 14mapblock ::= "map-block" ifname lhs "->" ipmask [ ports ] mapoptions . 15redir ::= "rdr" ifname rlhs "->" ip [ "," ip ] rdrport rdroptions . | 39nif="ppp0"; 40map $nif 0/0 -> 0/32 41.fi 42.PP 43would become 44.nf |
| 16 | 45 |
| 17lhs ::= ipmask | fromto . 18rlhs ::= ipmask dport | fromto . 19dport ::= "port" portnum [ "-" portnum ] . 20ports ::= "ports" numports | "auto" . 21rdrport ::= "port" portnum . 22mapit ::= "map" | "bimap" . 23fromto ::= "from" object "to" object . 24ipmask ::= ip "/" bits | ip "/" mask | ip "netmask" mask . 25dstipmask ::= ipmask | "range" ip "-" ip . 26mapicmp ::= "icmpidmap" "icmp" number ":" number . 27mapport ::= "portmap" tcpudp portspec . 28mapoptions ::= [ tcpudp ] [ "frag" ] [ age ] [ clamp ] . 29rdroptions ::= rdrproto [ rr ] [ "frag" ] [ age ] [ clamp ] [ rdrproxy ] . | 46map ppp0 0/0 -> 0/32 47.fi 48.PP 49Variables can be used recursively, such as 'foo="$bar baz";', so long as 50$bar exists when the parser reaches the assignment for foo. 51.PP 52See 53.B ipnat(8) 54for instructions on how to define variables to be used from a shell 55environment. 56.SH OUTBOUND SOURCE TRANSLATION (map'ing) 57Changing the source address of a packet is traditionally performed using 58.B map 59rules. Both the source address and optionally port number can be changed 60according to various controls. 61.PP 62To start out with, a common rule used is of the form: 63.nf |
| 30 | 64 |
| 31object :: = addr [ port-comp | port-range ] . 32addr :: = "any" | nummask | host-name [ "mask" ipaddr | "mask" hexnumber ] . 33port-comp :: = "port" compare port-num . 34port-range :: = "port" port-num range port-num . 35rdrproto ::= tcpudp | protocol . | 65map le0 0/0 -> 0/32 66.fi 67.PP 68Here we're saying change the source address of all packets going out of 69le0 (the address/mask pair of 0/0 matching all packets) to that of the 70interface le0 (0/32 is a synonym for the interface's own address at 71the current point in time.) If we wanted to pass the packet through 72with no change in address, we would write it as: 73.nf |
| 36 | 74 |
| 37rr ::= "round-robin" . 38age ::= "age" decnumber [ "/" decnumber ] . 39clamp ::= "mssclamp" decnumber . 40tcpudp ::= "tcp/udp" | protocol . 41mapproxy ::= "proxy" "port" port proxy-name '/' protocol 42rdrproxy ::= "proxy" proxy-name . | 75map le0 0/0 -> 0/0 76.fi 77.PP 78If we only want to change a portion of our internal network and to a 79different address that is routed back through this host, we might do: 80.nf |
| 43 | 81 |
| 44protocol ::= protocol-name | decnumber . 45nummask ::= host-name [ "/" decnumber ] . 46portspec ::= "auto" | portnumber ":" portnumber . 47port ::= portnumber | port-name . 48portnumber ::= number { numbers } . 49ifname ::= 'A' - 'Z' { 'A' - 'Z' } numbers . | 82map le0 10.1.1.0/24 -> 192.168.55.3/32 83.fi 84.PP 85In some instances, we may have an entire subnet to map internal addresses 86out onto, in which case we can express the translation as this: 87.nf |
| 50 | 88 |
| 51numbers ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' . | 89map le0 10.0.0.0/8 -> 192.168.55.0/24 |
| 52.fi 53.PP | 90.fi 91.PP |
| 54For standard NAT functionality, a rule should start with \fBmap\fP and then 55proceeds to specify the interface for which outgoing packets will have their 56source address rewritten. | 92IPFilter will cycle through each of the 256 addresses in the 192.168.55.0/24 93address space to ensure that they all get used. |
| 57.PP | 94.PP |
| 58Packets which will be rewritten can only be selected by matching the original 59source address. A netmask must be specified with the IP address. | 95Of course this poses a problem for TCP and UDP, with many connections made, 96each with its own port number pair. If we're unlucky, translations can be 97dropped because the new address/port pair mapping already exists. To 98mitigate this problem, we add in port translation or port mapping: 99.nf 100 101map le0 10.0.0.0/8 -> 192.168.55.0/24 portmap tcp/udp auto 102.fi |
| 60.PP | 103.PP |
| 61The address selected for replacing the original is chosen from an IP#/netmask 62pair. A netmask of all 1's indicating a hostname is valid. A netmask of 6331 1's (255.255.255.254) is considered invalid as there is no space for 64allocating host IP#'s after consideration for broadcast and network 65addresses. | 104In this instance, the word "auto" tells IPFilter to calculate a private 105range of port numbers for each address on the LHS to use without fear 106of them being trampled by others. This can lead to problems if there are 107connections being generated mire quickly than IPFilter can expire them. 108In this instance, and if we want to get away from a private range of 109port numbers, we can say: 110.nf 111 112map le0 10.0.0.0/8 -> 192.168.55.0/24 portmap tcp/udp 5000:65000 113.fi |
| 66.PP | 114.PP |
| 67When remapping TCP and UDP packets, it is also possible to change the source 68port number. Either TCP or UDP or both can be selected by each rule, with a 69range of port numbers to remap into given as \fBport-number:port-number\fP. 70.SH COMMANDS 71There are four commands recognised by IP Filter's NAT code: 72.TP | 115And now each connection through le0 will add to the enumeration of 116the port number space 5000-65000 as well as the IP address subnet 117of 192.168.55.0/24. 118.PP 119If the new addresses to be used are in a consecutive range, rather 120than a complete subnet, we can express this as: 121.nf 122 123map le0 10.0.0.0/8 -> range 192.168.55.10-192.168.55.249 124 portmap tcp/udp 5000:65000 125.fi 126.PP 127This tells IPFilter that it has a range of 240 IP address to use, from 128192.168.55.10 to 192.168.55.249, inclusive. 129.PP 130If there were several ranges of addresses for use, we can use each one 131in a round-robin fashion as followed: 132.nf 133 134map le0 10.0.0.0/8 -> range 192.168.55.10-192.168.55.29 135 portmap tcp/udp 5000:65000 round-robin 136map le0 10.0.0.0/8 -> range 192.168.55.40-192.168.55.49 137 portmap tcp/udp 5000:65000 round-robin 138.fi 139.PP 140To specify translation rules that impact a specific IP protocol, 141the protocol name or number is appended to the rule like this: 142.nf 143 144map le0 10.0.0.0/8 -> 192.168.55.0/24 tcp/udp 145map le0 10.0.0.0/8 -> 192.168.55.1/32 icmp 146map le0 10.0.0.0/8 -> 192.168.55.2/32 gre 147.fi 148.PP 149For TCP connections exiting a connection such as PPPoE where the MTU is 150slightly smaller than normal ethernet, it can be useful to reduce the 151Maximum Segment Size (MSS) offered by the internal machines to match, 152reducing the liklihood that the either end will attempt to send packets 153that are too big and result in fragmentation. This is acheived using the 154.B mssclamp 155option with TCP |
| 73.B map | 156.B map |
| 74that is used for mapping one address or network to another in an unregulated 75round robin fashion; | 157rules like this: 158.nf 159 160map pppoe0 0/0 -> 0/32 mssclamp 1400 tcp 161.fi 162.PP 163For ICMP packets, we can map the ICMP id space in query packets: 164.nf 165 166map le0 10.0.0.0/8 -> 192.168.55.1/32 icmpidmap icmp 1000:20000 167.fi 168.PP 169If we wish to be more specific about our initial matching criteria on the 170LHS, we can expand to using a syntax more similar to that in 171.B ipf.conf(5) 172: 173.nf 174 175map le0 from 10.0.0.0/8 to 26.0.0.0/8 -> 176 192.168.55.1 177map le0 from 10.0.0.0/8 port > 1024 to 26.0.0.0/8 -> 178 192.168.55.2 portmap 5000:9999 tcp/udp 179map le0 from 10.0.0.0/8 ! to 26.0.0.0/8 -> 180 192.168.55.3 portmap 5000:9999 tcp/udp 181.fi |
| 76.TP | 182.TP |
| 77.B rdr 78that is used for redirecting packets to one IP address and port pair to 79another; 80.TP 81.B bimap 82for setting up bidirectional NAT between an external IP address and an internal 83IP address and 84.TP | 183.B NOTE: 184negation matching with source addresses is 185.B NOT 186possible with 187.B map 188/ |
| 85.B map-block | 189.B map-block |
| 86which sets up static IP address based translation, based on a algorithm to 87squeeze the addresses to be translated into the destination range. 88.SH MATCHING | 190rules. |
| 89.PP | 191.PP |
| 90For basic NAT and redirection of packets, the address subject to change is used 91along with its protocol to check if a packet should be altered. The packet 92\fImatching\fP part of the rule is to the left of the "->" in each rule. | 192The NAT code has builtin default timeouts for TCP, UDP, ICMP and another 193for all other protocols. In general, the timeout for an entry to be 194deleted shrinks once a reply packet has been seen (excluding TCP.) 195If you wish to specify your own timeouts, this can be achieved either 196by setting one timeout for both directions: 197.nf 198 199map le0 0/0 -> 0/32 gre age 30 200.fi |
| 93.PP | 201.PP |
| 94Matching of packets has now been extended to allow more complex compares. 95In place of the address which is to be translated, an IP address and port 96number comparison can be made using the same expressions available with 97\fBipf\fP. A simple NAT rule could be written as: | 202or setting a different timeout for the reply: 203.nf 204 205map le0 from any to any port = 53 -> 0/32 age 60/10 udp 206.fi 207.PP 208A pressing problem that many people encounter when using NAT is that the 209address protocol can be embedded inside an application's communication. 210To address this problem, IPFilter provides a number of built-in proxies 211for the more common trouble makers, such as FTP. These proxies can be 212used as follows: 213.nf 214 215map le0 0/0 -> 0/32 proxy port 21 ftp/tcp 216.fi 217.PP 218In this rule, the word "proxy" tells us that we want to connect up this 219translation with an internal proxy. The "port 21" is an extra restriction 220that requires the destination port number to be 21 if this rule is to be 221activated. The word "ftp" is the proxy identifier that the kernel will 222try and resolve internally, "tcp" the protocol that packets must match. 223.PP 224See below for a list of proxies and their relative staus. 225.PP 226To associate NAT rules with filtering rules, it is possible to set and 227match tags during either inbound or outbound processing. At present the 228tags for forwarded packets are not preserved by forwarding, so once the 229packet leaves IPFilter, the tag is forgotten. For 230.B map 231rules, we can match tags set by filter rules like this: 232.nf 233 234map le0 0/0 -> 0/32 proxy portmap 5000:5999 tag lan1 tcp 235.fi 236.PP 237This would be used with "pass out" rules that includes a stanza such 238as "set-tag (nat = lan1)". 239.PP 240If the interface in which packets are received is different from the 241interface on which packets are sent out, then the translation rule needs 242to be written to take this into account: 243.nf 244 245map hme0,le0 0/0 -> 0/32 246.fi 247.PP 248Although this might seem counterintuitive, the interfaces when listed 249in rules for 250.B ipnat.conf 251are always in the 252.I inbound 253, 254.I outbound 255order. In this case, hme0 would be the return interface and le0 would be 256the outgoing interface. If you wish to allow return packets on any 257interface, the correct syntax to use would be: 258.nf 259 260map *,le0 0/0 -> 0/32 261.fi |
| 98.LP | 262.LP |
| 263A special variant of 264.B map 265rules exists, called 266.B map-block. 267This command is intended for use when there is a large network to be mapped 268onto a smaller network, where the difference in netmasks is upto 14 bits 269difference in size. This is achieved by dividing the address space and 270port space up to ensure that each source address has its own private range 271of ports to use. For example, this rule: |
|
| 99.nf | 272.nf |
| 100map de0 10.1.0.0/16 -> 201.2.3.4/32 | 273 274map-block ppp0 172.192.0.0/16 -> 209.1.2.0/24 ports auto |
| 101.fi | 275.fi |
| 276.PP 277would result in 172.192.0.0/24 being mapped to 209.1.2.0/32 278with each address, from 172.192.0.0 to 172.192.0.255 having 252 ports of its 279own. As opposed to the above use of \fBmap\fP, if for some reason the user 280of (say) 172.192.0.2 wanted 260 simultaneous connections going out, they would 281be limited to 252 with \fBmap-block\fP but would just \fImove on\fP to the next 282IP address with the \fBmap\fP command. 283.SS Extended matching 284.PP 285If it is desirable to match on both the source and destination of a packet 286before applying an address translation to it, this can be achieved by using 287the same from-to syntax as is used in \fBipf.conf\fP(5). What follows 288applies equally to the 289.B map 290rules discussed above and 291.B rdr 292rules discussed below. A simple example is as follows: 293.nf 294 295map bge0 from 10.1.0.0/16 to 192.168.1.0/24 -> 172.12.1.4 296.fi 297.PP 298This would only match packets that are coming from hosts that have a source 299address matching 10.1.0.0/16 and a destination matching 192.168.1.0/24. 300This can be expanded upon with ports for TCP like this: 301.nf 302 303rdr bge0 from 10.1.0.0/16 to any port = 25 -> 127.0.0.1 port 2501 tcp 304.fi 305.PP 306Where only TCP packets from 10.1.0.0/16 to port 25 will be redirected to 307port 2501. 308.PP 309As with \fBipf.conf\fR(5), if we have a large set of networks or addresses 310that we would like to match up with then we can define a pool using 311\fBippool\fR(8) in \fBippool.conf\fR(5) and then refer to it in an 312\fBipnat\fR rule like this: 313.nf 314 315map bge0 from pool/100 to any port = 25 -> 127.0.0.1 port 2501 tcp 316.fi 317.TP 318.B NOTE: 319In this situation, the rule is considered to have a netmask of "0" and 320thus is looked at last, after any rules with /16's or /24's in them, 321.I even if 322the defined pool only has /24's or /32's. Pools may also be used 323.I wherever 324the from-to syntax in \fBipnat.conf\fR(5) is allowed. 325.SH INBOUND DESTINATION TRANSLATION (redirection) 326.PP 327Redirection of packets is used to change the destination fields in a packet 328and is supported for packets that are moving \fIin\fP on a network interface. 329While the same general syntax for 330.B map 331rules is supported, there are differences and limitations. 332.PP 333Firstly, by default all redirection rules target a single IP address, not 334a network or range of network addresses, so a rule written like this: 335.nf 336 337rdr le0 0/0 -> 192.168.1.0 338.fi 339.PP 340Will not spread packets across all 256 IP addresses in that class C network. 341If you were to try a rule like this: 342.nf 343 344rdr le0 0/0 -> 192.168.1.0/24 345.fi 346.PP 347then you will receive a parsing error. 348.PP 349The from-to source-destination matching used with 350.B map 351rules can be used with rdr rules, along with negation, however the 352restriction moves - only a source address match can be negated: 353.nf 354 355rdr le0 from 1.1.0.0/16 to any -> 192.168.1.3 356rdr le0 ! from 1.1.0.0/16 to any -> 192.168.1.4 357.fi 358.PP 359If there is a consective set of addresses you wish to spread the packets 360over, then this can be done in one of two ways, the word "range" optional 361to preserve: 362.nf 363 364rdr le0 0/0 -> 192.168.1.1 - 192.168.1.5 365rdr le0 0/0 -> range 192.168.1.1 - 192.168.1.5 366.fi 367.PP 368If there are only two addresses to split the packets across, the 369recommended method is to use a comma (",") like this: 370.nf 371 372rdr le0 0/0 -> 192.168.1.1,192.168.1.2 373.fi 374.PP 375If there is a large group of destination addresses that are somewhat 376disjoint in nature, we can cycle through them using a 377.B round-robin 378technique like this: 379.nf 380 381rdr le0 0/0 -> 192.168.1.1,192.168.1.2 round-robin 382rdr le0 0/0 -> 192.168.1.5,192.168.1.7 round-robin 383rdr le0 0/0 -> 192.168.1.9 round-robin 384.fi 385.PP 386If there are a large number of redirect rules and hosts being targetted 387then it may be desirable to have all those from a single source address 388be targetted at the same destination address. To achieve this, the 389word 390.B sticky 391is appended to the rule like this: 392.nf 393 394rdr le0 0/0 -> 192.168.1.1,192.168.1.2 sticky 395rdr le0 0/0 -> 192.168.1.5,192.168.1.7 round-robin sticky 396rdr le0 0/0 -> 192.168.1.9 round-robin sticky 397.fi 398.PP 399The 400.B sticky 401feature can only be combined with 402.B round-robin 403and the use of comma. 404.PP 405For TCP and UDP packets, it is possible to both match on the destiantion 406port number and to modify it. For example, to change the destination port 407from 80 to 3128, we would use a rule like this: 408.nf 409 410rdr de0 0/0 port 80 -> 127.0.0.1 port 3128 tcp 411.fi 412.PP 413If a range of ports is given on the LHS and a single port is given on the 414RHS, the entire range of ports is moved. For example, if we had this: 415.nf 416 417rdr le0 0/0 port 80-88 -> 127.0.0.1 port 3128 tcp 418.fi 419.PP 420then port 80 would become 3128, port 81 would become 3129, etc. If we 421want to redirect a number of different pots to just a single port, an 422equals sign ("=") is placed before the port number on the RHS like this: 423.nf 424 425rdr le0 0/0 port 80-88 -> 127.0.0.1 port = 3128 tcp 426.fi 427.PP 428In this case, port 80 goes to 3128, port 81 to 3128, etc. 429.PP 430As with 431.B map 432rules, it is possible to manually set a timeout using the 433.B age 434option, like this: 435.nf 436 437rdr le0 0/0 port 53 -> 127.0.0.1 port 10053 udp age 5/5 438.fi 439.PP 440The use of proxies is not restricted to 441.B map 442rules and outbound sessions. Proxies can also be used with redirect 443rules, although the syntax is slightly different: 444.nf 445 446rdr ge0 0/0 port 21 -> 127.0.0.1 port 21 tcp proxy ftp 447.fi 448.PP 449For 450.B rdr 451rules, the interfaces supplied are in the same order as 452.B map 453rules - input first, then output. In situations where the outgoing interface 454is not certain, it is also possible to use a wildcard ("*") to effect a match 455on any interface. 456.nf 457 458rdr le0,* 0/0 -> 192.168.1.0 459.fi 460.PP 461A single rule, with as many options set as possible would look something like 462this: 463.nf 464 465rdr le0,ppp0 9.8.7.6/32 port 80 -> 1.1.1.1,1.1.1.2 port 80 tcp 466 round-robin frag age 40/40 sticky mssclamp 1000 tag tagged 467.fi 468.SH REWRITING SOURCE AND DESTINATION 469.PP 470Whilst the above two commands provide a lot of flexibility in changing 471addressing fields in packets, often it can be of benefit to translate 472\fIboth\fP source \fBand\fR destination at the same time or to change 473the source address on input or the destination address on output. 474Doing all of these things can be accomplished using 475.B rewrite 476NAT rules. 477.PP 478A 479.B rewrite 480rule requires the same level of packet matching as before, protocol and 481source/destination information but in addition allows either 482.B in 483or 484.B out 485to be specified like this: 486.nf 487 488rewrite in on ppp0 proto tcp from any to any port = 80 -> 489 src 0/0 dst 127.0.0.1,3128; 490rewrite out on ppp0 from any to any -> 491 src 0/32 dst 10.1.1.0/24; 492.fi 493.PP 494On the RHS we can specify both new source and destination information to place 495into the packet being sent out. As with other rules used in 496\fBipnat.conf\fR, there are shortcuts syntaxes available to use the original 497address information (\fB0/0\fR) and the address associated with the network 498interface (\fB0/32\fR.) For TCP and UDP, both address and port information 499can be changed. At present it is only possible to specify either a range of 500port numbers to be used (\fBX-Y\fR) or a single port number (\fB= X\fR) as 501follows: 502.nf 503 504rewrite in on le0 proto tcp from any to any port = 80 -> 505 src 0/0,2000-20000 dst 127.0.0.1,port = 3128; 506.fi 507.PP 508There are four fields that are stepped through in enumerating the number 509space available for creating a new destination: |
|
| 102.LP | 510.LP |
| 103or as | 511source address |
| 104.LP | 512.LP |
| 513source port 514.LP 515destination address 516.LP 517destination port 518.PP 519If one of these happens to be a static then it will be skipped and the next 520one incremented. As an example: |
|
| 105.nf | 521.nf |
| 106map de0 from 10.1.0.0/16 to any -> 201.2.3.4/32 | 522 523rewrite out on le0 proto tcp from any to any port = 80 -> 524 src 1.0.0.0/8,5000-5999 dst 2.0.0.0/24,6000-6999; |
| 107.fi | 525.fi |
| 526.PP 527The translated packets would be: |
|
| 108.LP | 528.LP |
| 109Only IP address and port numbers can be compared against. This is available 110with all NAT rules. 111.SH TRANSLATION | 5291st src=1.0.0.1,5000 dst=2.0.0.1,6000 530.LP 5312nd src=1.0.0.2,5000 dst=2.0.0.1,6000 532.LP 5333rd src=1.0.0.2,5001 dst=2.0.0.1,6000 534.LP 5354th src=1.0.0.2,5001 dst=2.0.0.2,6000 536.LP 5375th src=1.0.0.2,5001 dst=2.0.0.2,6001 538.LP 5396th src=1.0.0.3,5001 dst=2.0.0.2,6001 |
| 112.PP | 540.PP |
| 113To the right of the "->" is the address and port specification which will be 114written into the packet providing it has already successfully matched the 115prior constraints. The case of redirections (\fBrdr\fP) is the simplest: 116the new destination address is that specified in the rule. For \fBmap\fP 117rules, the destination address will be one for which the tuple combining 118the new source and destination is known to be unique. If the packet is 119either a TCP or UDP packet, the destination and source ports come into the 120equation too. If the tuple already exists, IP Filter will increment the 121port number first, within the available range specified with \fBportmap\fP 122and if there exists no unique tuple, the source address will be incremented 123within the specified netmask. If a unique tuple cannot be determined, then 124the packet will not be translated. The \fBmap-block\fP is more limited in 125how it searches for a new, free and unique tuple, in that it will used an 126algorithm to determine what the new source address should be, along with the 127range of available ports - the IP address is never changed and nor does the 128port number ever exceed its allotted range. 129.SH ICMPIDMAP | 541and so on. |
| 130.PP | 542.PP |
| 131ICMP messages can be divided into two groups: "errors" and "queries". ICMP 132errors are generated as a response of another IP packet. IP Filter will take 133care that ICMP errors that are the response of a NAT-ed IP packet are 134handled properly. | 543As with 544.B map 545rules, it is possible to specify a range of addresses by including the word 546\fIrange\fR before the addresses: 547.nf 548 549rewrite from any to any port = 80 -> 550 src 1.1.2.3 - 1.1.2.6 dst 2.2.3.4 - 2.2.3.6; 551.fi 552.SH DIVERTING PACKETS |
| 135.PP | 553.PP |
| 136For 4 types of ICMP queries (echo request, timestamp request, information 137request and address mask request) IP Filter supports an additional mapping 138called "ICMP id mapping". All these 4 types of ICMP queries use a unique 139identifier called the ICMP id. This id is set by the process sending the 140ICMP query and it is usually equal to the process id. The receiver of the 141ICMP query will use the same id in its response, thus enabling the 142sender to recognize that the incoming ICMP reply is intended for him and is 143an answer to a query that he made. The "ICMP id mapping" feature modifies 144these ICMP id in a way identical to \fBportmap\fP for TCP or UDP. | 554If you'd like to send packets to a UDP socket rather than just another 555computer to be decapsulated, this can be achieved using a 556.B divert 557rule. |
| 145.PP | 558.PP |
| 146The reason that you might want this, is that using this feature you don't 147need an IP address per host behind the NAT box, that wants to do ICMP queries. 148The two numbers behind the \fBicmpidmap\fP keyword are the first and the 149last icmp id number that can be used. There is one important caveat: if you 150map to an IP address that belongs to the NAT box itself (notably if you have 151only a single public IP address), then you must ensure that the NAT box does 152not use the \fBicmpidmap\fP range that you specified in the \fBmap\fP rule. 153Since the ICMP id is usually the process id, it is wise to restrict the 154largest permittable process id (PID) on your operating system to e.g. 63999 and 155use the range 64000:65535 for ICMP id mapping. Changing the maximal PID is 156system dependent. For most BSD derived systems can be done by changing 157PID_MAX in /usr/include/sys/proc.h and then rebuild the system. | 559Divert rules can be be used with both inbound and outbound packet 560matching however the rule 561.B must 562specify host addresses for the outer packet, not ranges of addresses 563or netmasks, just single addresses. 564Additionally the syntax must supply required information for UDP. 565An example of what a divert rule looks ike is as follows: 566.nf 567 568divert in on le0 proto udp from any to any port = 53 -> 569 src 192.1.1.1,54 dst 192.168.1.22.1,5300; 570.fi 571.PP 572On the LHS is a normal set of matching capabilities but on the RHS it is 573a requirement to specify both the source and destination addresses and 574ports. 575.PP 576As this feature is intended to be used with targetting packets at sockets 577and not IPFilter running on other systems, there is no rule provided to 578\fIundivert\fR packets. 579.TP 580.B NOTE: 581Diverted packets \fImay\fP be fragmented if the addition of the 582encapsulating IP header plus UDP header causes the packet to exceed 583the size allowed by the outbound network interface. At present it is 584not possible to cause Path MTU discovery to happen as this feature 585is intended to be transparent to both endpoints. 586.B Path MTU Discovery 587If Path MTU discovery is being used and the "do not fragment" flag 588is set in packets to be encapsulated, an ICMP error message will 589be sent back to the sender if the new packet would need to be 590fragmented. 591.SH COMMON OPTIONS 592This section deals with options that are available with all rules. 593.TP 594.B purge 595When the purge keyword is added to the end of a NAT rule, it will 596cause all of the active NAT sessions to be removed when the rule 597is removed as an individual operation. If all of the NAT rules 598are flushed out, it is expected that the operator will similarly 599flush the NAT table and thus NAT sessions are not removed when the 600NAT rules are flushed out. 601.SH RULE ORDERING 602.PP 603.B NOTE: 604Rules in 605.B ipnat.conf 606are read in sequentially as listed and loaded into the kernel in this 607fashion 608.B BUT 609packet matching is done on \fBnetmask\fR, going from 32 down to 0. 610If a rule uses 611.B pool 612or 613.B hash 614to reference a set of addresses or networks, the netmask value for 615these fields is considered to be "0". 616So if your 617.B ipnat.conf 618has the following rules: 619.nf 620 621rdr le0 192.0.0.0/8 port 80 -> 127.0.0.1 3132 tcp 622rdr le0 192.2.0.0/16 port 80 -> 127.0.0.1 3131 tcp 623rdr le0 from any to pool/100 port 80 -> 127.0.0.1 port 3130 tcp 624rdr le0 192.2.2.0/24 port 80 -> 127.0.0.1 3129 tcp 625rdr le0 192.2.2.1 port 80 -> 127.0.0.1 3128 tcp 626.fi 627.PP 628then the rule with 192.2.2.1 will match \fBfirst\fR, regardless of where 629it appears in the ordering of the above rules. In fact, the order in 630which they would be used to match a packet is: 631.nf 632 633rdr le0 192.2.2.1 port 80 -> 127.0.0.1 3128 tcp 634rdr le0 192.2.2.0/24 port 80 -> 127.0.0.1 3129 tcp 635rdr le0 192.2.0.0/16 port 80 -> 127.0.0.1 3131 tcp 636rdr le0 192.0.0.0/8 port 80 -> 127.0.0.1 3132 tcp 637rdr le0 from any to pool/100 port 80 -> 127.0.0.1 port 3130 tcp 638.fi 639.PP 640where the first line is actually a /32. 641.PP 642If your 643.B ipnat.conf 644file has entries with matching target fields (source address for 645.B map 646rules and destination address for 647.B rdr 648rules), then the ordering in the 649.B ipnat.conf 650file does matter. So if you had the following: 651.nf 652 653rdr le0 from 1.1.0.0/16 to 192.2.2.1 port 80 -> 127.0.0.1 3129 tcp 654rdr le0 from 1.1.1.0/24 to 192.2.2.1 port 80 -> 127.0.0.1 3128 tcp 655.fi 656.PP 657Then no packets will match the 2nd rule, they'll all match the first. 658.SH IPv6 659.PP 660In all of the examples above, where an IPv4 address is present, an IPv6 661address can also be used. All rules must use either IPv4 addresses with 662both halves of the NAT rule or IPv6 addresses for both halves. Mixing 663IPv6 addresses with IPv4 addresses, in a single rule, will result in an 664error. 665.PP 666For shorthand notations such as "0/32", the equivalent for IPv6 is 667"0/128". IPFilter will treat any netmask greater than 32 as an 668implicit direction that the address should be IPv6, not IPv4. 669To be unambiguous with 0/0, for IPv6 use ::0/0. |
| 158.SH KERNEL PROXIES 159.PP 160IP Filter comes with a few, simple, proxies built into the code that is loaded 161into the kernel to allow secondary channels to be opened without forcing the 162packets through a user program. The current state of the proxies is listed 163below, as one of three states: 164.HP 165Aging - protocol is roughly understood from --- 6 unchanged lines hidden (view full) --- 172Experimental - rough support for the protocol at best, may or may not 173work as testing has been at best sporadic, possible large scale changes 174to the code in order to properly support the protocol. 175.HP 176Mature - well tested, protocol is properly 177understood by the proxy; 178.PP 179The currently compiled in proxy list is as follows: | 670.SH KERNEL PROXIES 671.PP 672IP Filter comes with a few, simple, proxies built into the code that is loaded 673into the kernel to allow secondary channels to be opened without forcing the 674packets through a user program. The current state of the proxies is listed 675below, as one of three states: 676.HP 677Aging - protocol is roughly understood from --- 6 unchanged lines hidden (view full) --- 684Experimental - rough support for the protocol at best, may or may not 685work as testing has been at best sporadic, possible large scale changes 686to the code in order to properly support the protocol. 687.HP 688Mature - well tested, protocol is properly 689understood by the proxy; 690.PP 691The currently compiled in proxy list is as follows: |
| 180.HP | 692.TP |
| 181FTP - Mature | 693FTP - Mature |
| 182.HP | 694(map ... proxy port ftp ftp/tcp) 695.TP |
| 183IRC - Experimental | 696IRC - Experimental |
| 184.HP | 697(proxy port 6667 irc/tcp) 698.TP |
| 185rpcbind - Experimental | 699rpcbind - Experimental |
| 186.HP | 700.TP 701PPTP - Experimental 702.TP |
| 187H.323 - Experimental | 703H.323 - Experimental |
| 188.HP | 704(map ... proxy port 1720 h323/tcp) 705.TP |
| 189Real Audio (PNA) - Aging | 706Real Audio (PNA) - Aging |
| 190.HP | 707.TP 708DNS - Developmental 709(map ... proxy port 53 dns/udp { block .cnn.com; }) 710.TP |
| 191IPsec - Developmental | 711IPsec - Developmental |
| 192.HP | 712(map ... proxy port 500 ipsec/tcp) 713.TP |
| 193netbios - Experimental | 714netbios - Experimental |
| 194.HP | 715.TP |
| 195R-command - Mature | 716R-command - Mature |
| 196 197.SH TRANSPARENT PROXIES 198.PP 199True transparent proxying should be performed using the redirect (\fBrdr\fP) 200rules directing ports to localhost (127.0.0.1) with the proxy program doing 201a lookup through \fB/dev/ipnat\fP to determine the real source and address 202of the connection. 203.SH LOAD-BALANCING 204.PP 205Two options for use with \fBrdr\fP are available to support primitive, 206\fIround-robin\fP based load balancing. The first option allows for a 207\fBrdr\fP to specify a second destination, as follows: 208.LP 209.nf 210rdr le0 203.1.2.3/32 port 80 -> 203.1.2.3,203.1.2.4 port 80 tcp 211.fi 212.LP 213This would send alternate connections to either 203.1.2.3 or 203.1.2.4. 214In scenarios where the load is being spread amongst a larger set of 215servers, you can use: 216.LP 217.nf 218rdr le0 203.1.2.3/32 port 80 -> 203.1.2.3,203.1.2.4 port 80 tcp round-robin 219rdr le0 203.1.2.3/32 port 80 -> 203.1.2.5 port 80 tcp round-robin 220.fi 221.LP 222In this case, a connection will be redirected to 203.1.2.3, then 203.1.2.4 223and then 203.1.2.5 before going back to 203.1.2.3. In accomplishing this, 224the rule is removed from the top of the list and added to the end, 225automatically, as required. This will not effect the display of rules 226using "ipnat -l", only the internal application order. 227.SH EXAMPLES 228.PP 229This section deals with the \fBmap\fP command and its variations. 230.PP 231To change IP#'s used internally from network 10 into an ISP provided 8 bit 232subnet at 209.1.2.0 through the ppp0 interface, the following would be used: 233.LP 234.nf 235map ppp0 10.0.0.0/8 -> 209.1.2.0/24 236.fi 237.PP 238The obvious problem here is we're trying to squeeze over 16,000,000 IP 239addresses into a 254 address space. To increase the scope, remapping for TCP 240and/or UDP, port remapping can be used; 241.LP 242.nf 243map ppp0 10.0.0.0/8 -> 209.1.2.0/24 portmap tcp/udp 1025:65000 244.fi 245.PP 246which falls only 527,566 `addresses' short of the space available in network 24710. If we were to combine these rules, they would need to be specified as 248follows: 249.LP 250.nf 251map ppp0 10.0.0.0/8 -> 209.1.2.0/24 portmap tcp/udp 1025:65000 252map ppp0 10.0.0.0/8 -> 209.1.2.0/24 253.fi 254.PP 255so that all TCP/UDP packets were port mapped and only other protocols, such as 256ICMP, only have their IP# changed. In some instances, it is more appropriate 257to use the keyword \fBauto\fP in place of an actual range of port numbers if 258you want to guarantee simultaneous access to all within the given range. 259However, in the above case, it would default to 1 port per IP address, since 260we need to squeeze 24 bits of address space into 8. A good example of how 261this is used might be: 262.LP 263.nf 264map ppp0 172.192.0.0/16 -> 209.1.2.0/24 portmap tcp/udp auto 265.fi 266.PP 267which would result in each IP address being given a small range of ports to 268use (252). In all cases, the new port number that is used is deterministic. 269That is, port X will always map to port Y. 270WARNING: It is not advisable to use the \fBauto\fP feature if you are map'ing 271to a /32 (i.e. 0/32) because the NAT code will try to map multiple hosts to 272the same port number, outgoing and ultimately this will only succeed for one 273of them. 274The problem here is that the \fBmap\fP directive tells the NAT 275code to use the next address/port pair available for an outgoing connection, 276resulting in no easily discernible relation between external addresses/ports 277and internal ones. This is overcome by using \fBmap-block\fP as follows: 278.LP 279.nf 280map-block ppp0 172.192.0.0/16 -> 209.1.2.0/24 ports auto 281.fi 282.PP 283For example, this would result in 172.192.0.0/24 being mapped to 209.1.2.0/32 284with each address, from 172.192.0.0 to 172.192.0.255 having 252 ports of its 285own. As opposed to the above use of \fBmap\fP, if for some reason the user 286of (say) 172.192.0.2 wanted 260 simultaneous connections going out, they would 287be limited to 252 with \fBmap-block\fP but would just \fImove on\fP to the next 288IP address with the \fBmap\fP command. | 717(map ... proxy port shell rcmd/tcp) 718.SH KERNEL PROXIES 719.SH FILES |
| 289/dev/ipnat 290.br | 720/dev/ipnat 721.br |
| 722/etc/protocols 723.br |
|
| 291/etc/services 292.br 293/etc/hosts 294.SH SEE ALSO 295ipnat(4), hosts(5), ipf(5), services(5), ipf(8), ipnat(8) | 724/etc/services 725.br 726/etc/hosts 727.SH SEE ALSO 728ipnat(4), hosts(5), ipf(5), services(5), ipf(8), ipnat(8) |