There have been various questions about doing real NAT on Linux. I'd like
to open this discussion to find out exactly what people want, and how to
control NAT.
Currently Linux has IP Masquerading, which is a particular degenerate form
of NAT where all masqueraded hosts are faked as coming from a single IP
address using port numbers (on the masquerading host) and a session table
to separate connections.
I think there are 2 other forms of NAT:-
Static NAT - where the original IP range and the remapped IP range have
a
1:1 relationship, thus allowing incoming services to be handled as well.
Dynamic NAT - where the original IP range is larger than the remapped IP
range, and when an internal host accesses something outside the internal
network it is given an external address on some form of lease.
Management of these leases adds a whole new layer of complexity.
Connection back to Dynamically NAT-ed hosts is possible while the lease
persists.
The basic difference between these is the lease management. Port
remapping, as done by IP filter[2] is also possible.
I guess that if we can specify things correctly, we should be able to come
up with a model which will support all of these forms, including
masquerading.
Another side effect of NAT is that the box will need to answer on a range
of IP addresses. These are effectively aliased interfaces. Should they
be setup dynamically as needed by the kernel code, or should they be
explicity configured by (someone) configuring aliases at boot time??
I think that these functions should all be controlled by additional
information on the forwarding firewall. This means we need to redesign
the firewall data structures, and also decide whether the input/output
firewalls (which do not need all this extra information) need to match the
forwarding firewall structures or not! Actually the easiest thing to do I
guess is to add a pointer to an additional structure which describes the
extra information required.
One possible question is should we take the IP Filter setup and slot that
into 2.1?
Certainly the filter language is much better and more comprehensible for
IP filter, *but* that is really a case of having an external tool that
converts the language into ioctls.
Comments on how to take this all forward, gladly accepted!
Refs
1. RFC1613 basically describes NAT.
2. IP Filter implements most of this stuff. It can be found at
http://coombs.anu.edu.au/~avalon/
Nigel.
-- [ Nigel.Metheringham@theplanet.net - Unix Applications Engineer ] [ *Views expressed here are personal and not supported by PLAnet* ] [ PLAnet Online : The White House Tel : +44 113 251 6012 ] [ Melbourne Street, Leeds LS2 7PS UK. Fax : +44 113 2345656 ] [Q: You know when you run sendmail.... A: No, you DELETE sendmail]