Ciaran,
some comments in-line:
At 19:14 6/10/97 +0200, Ciaran Deignan wrote:
...<SNIP>...
>Basically the new dyanmic address translation in netwall replaces the calling
>address and port number in TCP and UDP "connection" requests coming from a
>"mapable" host by the IP address of the interface by which the packet exits
>the machine. The source port is replaced by a number grater than 65000.
>
>For starters I've no idea how its possible to generate TCP frames with source
>port numbers grater than 2 to-the-power-of 16. But I suppose its
documented in
>an RFC somewhere.
You cannot do this, TCP/UDP ports are 16 bits so must be less than the magic
number 65.535
BTW, with Network Address Translation, NAT, usually only the IP address
is translated leaving the UDP/TCP ports unchanged. There is a RFC describing
NAT (RFC 1631 but I'm not sure about the number).
If you want to change also the UDP/TCP port (e.g. to allow the use of
a single official IP address to hide your internal network), then:
- you should try to keep the implicit meaning of ports by keeping the
ranges < 1024 and > 1024 apart
- you should also translate INTO the UDP/TCP payload for some protocols
>
>I've heard that this type of dynamic address translation has also been
>implemented by Cisco, and that its called "Source Port Multiplexing" or
>"Source Port Mapping" or something.
BTW I'm working for Cisco, so my comments are probably biased ;-)
Now we call this mechanism (changing the UDP/TCP ports when changing
the source IP address) PAT Port Address Translation.
>
>Obvoiusly this technology only supports TCP and UDP communications. However I
>have the unnerving feeling that some commonly-used services wont like this
>sort of magic. The engineering has told me that FTP is supported, but
>what about sendmail?
Hummm hummmm FTP is not easy, you have to check/translate the PORT PASV
commands
as well ! sendmail/SMTP will be fine.
But think about GRE (directly above IP) which is part of Microsoft PPTP.
>
>Has anybody had any experience with a real-life application of this sort of
>technology, and are there any "gotchas" that you could help us avoid?
>
>Thanks
>Ciaran
>
Bonne chance (ou devrais dire bonne M....)
-eric
Eric Vyncke
Technical Consultant Cisco Systems Belgium SA/NV
Phone: +32-2-778.4677 Fax: +32-2-778.4300
E-mail: evyncke @
cisco .
com Mobile: +32-75-312.458
References:
|
|
