Home Page The Club Computers News Links Glossary EYAWTK
Before Amiga Background ICS OCS ECS AGA ??? PPC
U-Boot SLB Linux Amiga OS Dual Boot Motherboards Peripherals Other
Initialisation Installation OS4 Updates About OS4 File Systems Networking Printing Other
Introduction File System Workbench Preferences Commands Error Msgs Miscellaneous

AmigaOS 4.0 - About OS4 - Commands

IPNAT Networking
Purpose: To translate internal addresses to external addresses using NAT.
Format: IPNAT [ -aDFhnpstvxX ] [ -N <device> ] [ -o [NSI] ] [ -O [NSI] ]
[ -P <pidfile> ] [ -S <device> ] [ -f <device>&nnbsp';] [ <filename> ]
Template: (none)
IPNAT translates internal addresses to external addresses using Network Address Translation (NAT).

The format for files accepted by ipnat is described by the following grammar:

ipmap :: = mapblock | redir | map .

map ::= mapit ifname ipmask "->" ipmask [ mapport ] .
map ::= mapit ifname fromto "->" ipmask [ mapport ] .
mapblock ::= "map-block" ifname ipmask "->" ipmask [ ports ] .
redir ::= "rdr" ifname ipmask dport "->" ip [ "," ip ] [ ports ] options .

dport ::= "port" portnum [ "-" portnum ] .
ports ::= "ports" numports | "auto" .
mapit ::= "map" | "bimap" .
fromto ::= "from" object "to" object .
ipmask ::= ip "/" bits | ip "/" mask | ip "netmask" mask .
mapport ::= "portmap" tcpudp portnumber ":" portnumber .
options ::= [ tcpudp ] [ rr ] .

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 .

rr ::= "round-robin" .
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' .

For standard NAT functionality, a rule should start with map and then proceed to specify the interface for which outgoing packets will have their source address rewritten.

Packets which will be rewritten can only be selected by matching the original source address. A netmask must be specified with the IP address.

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 ( is considered invalid as there is no space for allocating host IP#'s after consideration for broadcast and network addresses.

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 port-number:port-number.

There are four commands recognised by IP Filter's NAT code:

map that is used for mapping one address or network to another in an unregulated round robin fashion.
rdr that is used for redirecting packets to one IP address and port pair to another.
bimap that is used for setting up bidirectional NAT between an external IP address and an internal IP address.
map-block that is used for setting up static IP address based translation, based on a algorithm to squeeze the addresses to be translated into the destination range.
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 matching part of the rule is to the left of the "->" in each rule. 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 ipf. A simple NAT rule could be written as: map de0 ->

or as

map de0 from to any ->

Only IP address and port numbers can be compared against. This is available with all NAT rules.

To the right of the "->" is the address and port specification which will be written into the packet providing it has already successful matched the prior constraints. The case of redirections (rdr) is the simpliest: the new destination address is that specified in the rule. For map 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 portmap 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 map-block 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.

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.

True transparent proxying should be performed using the redirect (rdr) rules directing ports to localhost ( with the proxy program doing a lookup through /dev/ipnat to determine the real source and address of the connection.

Two options for use with rdr are available to support primitive, round-robin based load balancing. The first option allows for a rdr to specify a second destination, as follows:

rdr le0 port 80 ->, port 80 tcp This would send alternate connections to either or In scenarios where the load is being spread amongst a larger set of servers, you can use: rdr le0 port 80 ->, port 80 tcp round-robin
rdr le0 port 80 -> port 80 tcp round-robin
In this case, a connection will be redirected to, then and then before going back to 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.

This section deals with the map command and it's variations.

To change IP#'s used internally from network 10 into an ISP provided 8 bit subnet at through the ppp0 interface, the following would be used:

map ppp0 -> 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; map ppp0 -> portmap tcp/udp 1025:65000 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: map ppp0 -> portmap tcp/udp 1025:65000
map ppp0 ->
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 auto 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: map ppp0 -> portmap tcp/udp auto which would result in each IP address being given a small range of ports to use (252). The problem here is that the map 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 map-block as follows: map-block ppp0 -> ports auto For example, this would result in being mapped to with each address, from to having 252 ports of its own. As opposed to the above use of map, if for some reason the user of (say) wanted 260 simultaneous connections going out, they would be limited to 252 with map-block but would just move on to the next IP address with the map command.

Return to Commands Selection

Disclaimer: Amiga Auckland have prepared the above information for the use of its members based on our experiences and as such is subject to revision at any time. Amiga Auckland cannot guarantee any of the information and cannot be held accountable for any issues that may result from using it.

Copyright 2006 Amiga Auckland Inc. All rights reserved.
Revised: February 9, 2006.