TFTP, NAT

Hello,

Is it possible to get TFTPd working through NAT?
If yes, how to do this?

Thanks in advance.
Vicky.


"I'm implementing a TFTP server with some local extensions, and I seem to
have run into a stumbling block with the NAT solution my employer is
using. When I run my TFTP client from an ``inside'' machine, the ``outside''
server gets the initial RRQ/WRQ packet, but the reply OACK (or whatever)
packet is getting lost. The local sysadmin asserts that this is happening
because the source port of the OACK packet dosn't match the original
destination port on the RRQ/WRQ.

In other words, he claims that a NAT entry for UDP *by design* can only
accomodate return packets from the specific IP/port combination that
was the destination of the UDP packet that caused the entry to be created.
This clearly breaks TFTP, which specifies that responses from the server
come from a separate socket with a unique TID (port) for the ``session''.

Is this truly how NAT is intended to work with UDP? Or is our Cisco
router just mis-configured in some subtle way?

IF this is how NAT is intended to work, I can attempt a work-around by
introducing a TFTP option (``plumb-nat'') that tells the server to use
the initial socket for the response, and encode the TID (port) in the
option acknowledgement... But obviously I'd prefer not to do this if
this is just a broken local configuration. :-/"

> Is it possible to get TFTPd working through NAT?
> If yes, how to do this?

With NAT yes, but behind a firewall, you have to have a very good reason.

> In other words, he claims that a NAT entry for UDP *by design* can only
> accomodate return packets from the specific IP/port combination that
> was the destination of the UDP packet that caused the entry to be created.
> This clearly breaks TFTP, which specifies that responses from the server
> come from a separate socket with a unique TID (port) for the ``session''.

Your sysadmin is right. Sysadmins generally are not too happy (includes me)
to
allow a connectionless protocol which uses UDP like TFTP. A TCP based
protocol such as FTP going
through a firewall is much more agreeable. Just allowing udp port 69 does
not work, the destination port will
change after the first packet are sent.

> Is this truly how NAT is intended to work with UDP? Or is our Cisco
> router just mis-configured in some subtle way?

One solution might be to try "secure tunneling" (I have not tried it). I
don't know how much of it is supported in your router.

--Turi