# TFTPD server woes



## Cinolt (Dec 5, 2016)

*TL;DR*: Please do NOT reply with "just use SSHD"; this thread is about TFTPD.

*Real TL;DR*: TFTPD will not send responses to IP addresses in the WAN, even though it receives requests from the WAN.

*Full Story*
FreeBSD 11.0-RELEASE-p1 AMD64

tftpd must be run from inetd, as /usr/libexec/tftpd appears to interface with a UDP socket as stdin.

/etc/rc.conf

```
inetd_enable="YES"
inetd_flags=""
```
/etc/inetd.conf

```
tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -d 15 -s /tftpboot
```
Now that inetd with tftpd is running, I can run tftp and `get` things as expected.

My FreeBSD system is within a residential NAT, but port forwarding has been setup properly to route TFTP traffic (UDP 69) to and from my FreeBSD system.

So, `tftp 127.0.0.1` works, `tftp lan_ip` works, *but* `tftp wan_ip` does not receive a response when I attempt to `get` something. Note that I'm actually typing in the LAN and WAN IP's when I run the commands.

My first reaction is to think that this is a port forwarding issue, however port forwarding is set up properly and tftp indicates that it actually receives packets from the WAN, as shown in /var/log/xferlog

```
Dec  4 18:19:32 temphost tftpd[1634]: Full access allowedin /etc/hosts.allow
Dec  4 18:19:32 temphost tftpd[1634]: Filename: 'a'
Dec  4 18:19:32 temphost tftpd[1634]: Mode: 'netascii'
Dec  4 18:19:32 temphost tftpd[1634]: 127.0.0.1: read request for a: File not found
Dec  4 18:19:37 temphost tftpd[1637]: Full access allowedin /etc/hosts.allow
Dec  4 18:19:37 temphost tftpd[1637]: Filename: 'a'
Dec  4 18:19:37 temphost tftpd[1637]: Mode: 'netascii'
Dec  4 18:19:37 temphost tftpd[1637]: _lan_ip_: read request for a: File not found
Dec  4 18:19:42 temphost tftpd[1640]: Full access allowedin /etc/hosts.allow
Dec  4 18:19:42 temphost tftpd[1640]: Filename: 'a'
Dec  4 18:19:42 temphost tftpd[1640]: Mode: 'netascii'
Dec  4 18:19:42 temphost tftpd[1640]: _wan_ip_: read request for a: File not found
```
(I *really* hope somebody doesn't reply with "oh youre just getting the wrong filename")

inetd apparently uses TCP Wrappers, which I should have disabled with `inetd_flags=""`, and just to be safe I replaced /etc/hosts.allow with:

```
ALL : ALL : allow
```
and xferlog indicates it has full access.

So, from this information I can conclude several possibilities.

tftpd bug? Probably not, since it works just fine with localhost and LAN IP.
tftp bug? Probably not, since I get the same behavior with another client such as atftp
Some FreeBSD mechanism, apart from TCP Wrapper, that treats the WAN IP as dangerous and prevents tftpd from emitting UDP packets towards them? This is the only thing I can conclude.
If anybody has any ideas as to what's going wrong, I would greatly appreciate it.


----------



## Cinolt (Dec 5, 2016)

Turns out that the TFTP, similar to FTP, has the server transmit the data from a random port back to the client. Guess I'll just have to use another protocol.

How the hell are FTP servers not a living nightmare for anyone behind a NAT?


----------



## tingo (Dec 6, 2016)

TFTP (like FTP and several other protocols) are very old protocols, designed when you (as in 'your company' or 'your university campus') usually had just one LAN, and most likely a very limited bandwidth leased line connection (or even dial-up) to the Internet. So at the time this protocol was designed, nobody thought that doing TFTP over Internet was a realistic scenario. The protocol will work, if your NAT is configured correctly.

FTP servers - nobody today is using FTP servers behind NAT unless they know how to configure their NAT correctly (and accept the level of work it requires). It is far, far easier to just use a more modern protocol that works more easily with NAT.

TL;DR - if you insist on using 20 or 30 year old protocols today, learn how to use them in today's environment. Do not complain - it only makes you look bad.


----------



## kpa (Dec 6, 2016)

FTP is still workable but you have to disable active mode and force passive mode on clients. Not because of the server side set up but because of the client side mess the active FTP mode causes.


----------



## balanga (Dec 6, 2016)

Cinolt said:


> Turns out that the TFTP, similar to FTP, has the server transmit the data from a random port back to the client. Guess I'll just have to use another protocol.
> 
> How the hell are FTP servers not a living nightmare for anyone behind a NAT?




Not exactly sure what you're trying to do, but have you ever come across iPXE (http://ipxe.org/)


----------



## Cinolt (Dec 7, 2016)

I actually was just trying out different ways to send a file between two hosts. Right now I am settling on just using HTTP, but I made this thread because I wanted to know why TFTPD was not working when it should be. Guess it's just a kind of OCD on my part.


----------



## da1 (Dec 8, 2016)

Cinolt said:


> How the hell are FTP servers not a living nightmare for anyone behind a NAT?


They are, that's why we have https://www.openbsd.org/faq/pf/ftp.html


----------



## Oko (Dec 8, 2016)

Cinolt said:


> Turns out that the TFTP, similar to FTP, has the server transmit the data from a random port back to the client. Guess I'll just have to use another protocol.
> 
> How the hell are FTP servers not a living nightmare for anyone behind a NAT?



When you did original post sounded like you knew what you were doing. I am not sure anymore. Either you really need TFTP server or you don't. I thought you were setting some kind PXE boot automated boot environment or bunch of thin client which would boot of your FreeBSD TFTP server. In both cases setting TFTP server is 3 minutes job. If you are not doing any of those two scenarios you are doing something wrong. What a heck is that NAT. NAT on your LAN?


----------



## wblock@ (Dec 8, 2016)

If the idea is "I need to share files from my server on the internet", TFTP is not the answer.  TFTP is the less-secure alternative to FTP, which is already bad enough.

It's not clear at all which type of files are being shared.  Certainly there is no lack of protocols that are faster and more secure than TFTP.


----------

