Homepage di Giacomo.

Network address and port translation (See also NAT scenarios).

IPFIREwall is able to translate packets so that they can be redirected to another host. Destination addresses and ports can be changed in the pre routing phase (see linux networking overview for details) or in the output phase, for locally generated packets. The last function is working only if the port is changed. IPFIRE is not able to deliver a locally generated packet to another machine if this implies a forwarding from an interface to another (i.e. eth0->ppp0).
Thanks to the network destination address translation it is possible to redirect a connection to another machine. If IPFIRE is installed on a gateway and a web server resides behind it, packets directed towards the web port, the number 80, can be redirected inside the private network to the web server. When inserting a new translation rule, a new address and in case a new port must be provided. If only the address is specified, the port is left unchanged, and viceversa. The remaining fields of the rule are evaluated at the same way they are inside the filtering algorithm.
Source network address translation has not been yet implemented, it's intended to change source addresses as they leave machine. An equivalent form of source network address translation has been applied on a gateway to the Internet: IP masquerading.
IP masquerading is a particular form of Source NAT in which the source address to be masqueraded is dynamically chosen reading the one of the network interface provided as device in the translation rule. This is useful for those connections having an ip dynamically assigned by an Internet service provider. It does not matter if the address changes at each dial-up connection: it is read every time translation is applied to that interface. For instance, if ppp0 is specified as the output device, then the outgoing packets are masqueraded with the ppp0 interface address.
Kernel work in translation routine does not end here: dynamic tables have to be set up to trace out the already natted connections, so that coming back packets are de-masqueraded or de-snatted or de-dnatted and the receiving machine thinks they really come from the remote host and not from the gateway/IPFIREwall. Note that in this environment only addresses and ports are changed and a tcp/udp checksum is always recalculated. No adjustments are done in window sizes or other tcp fields. Since the kernel translation tables, as well as the state tables and the logging tables, are dynamically allocated, they each have their own lifetime and there is a maximum amount of entries in their lists. Administrators should read kernel dynamic tables timeouts and numerousness chapter for details and notes.
As for the state tables, also the timings of the NAT tables is based on a state machine.
The port redirection has been tested to work with transparent proxying. Have a look at transparent proxying scenario for an example of transparent proxying combined with the execution of an email scanner.
Translated packets (source or destination) are printed on the screen together with filtered packets in input, output or forward directions.

Example: an external connection is redirected to an internal host.

As you can see in the screenshot above, an external host, having the IP address, connects to the gateway interface with address, and port 222. The NAT gateway is told to forward connections towards port 222 coming from to the internal host, port 22 (ssh server). Referring to the picture, in the first line you can see the connection setup packet arriving from the remote host, reaching the prerouting point. In the second log line, one can see that such packet is destination address and port translated, and so forwarded to, port 22.
Then the internal host sends back the answer directly to the external one, passing through the gateway anyway, since it always sends to it packets directed to the Internet. The NAT gateway recognizes an already seen translated flow, and in post routing phase changes source address and port, to make the remote host think that the response will be coming back from the public host rather than a private ssh server.
In the figure above, one can see also the state of the connection changing from setup to setup ok and finally (acknowledged connection) to established.

See also NAT scenarios for other examples of network address and port translation tested in this environment.

Valid XHTML 1.0!

Top of page
Back to index
Next page (Output DNAT (version 0.98.4 and following)
Previous page (Stateful connections)