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 158.110.144.168, connects to
the gateway interface with address 80.104.113.84, and port 222.
The NAT gateway is told to forward connections towards port 222 coming from 158.110.144.168
to the internal host 192.168.0.2, 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 192.168.0.2, 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 80.104.113.84 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.