2

I am attempting to get a really simple TFTP server up and running for the purpose of working as an IPXE boot server. However everything I seem to do doesn't seem to work to get the server to be able to communicate with a remote client. I can get the client to communicate across localhost which seems to work great.

tftp $TFTP_SERVER -c get README

While this works great on local host, it defeats the purpose of having a server who can talk remotely. The tftp config file reads as follows:

[root@ipxe tmp]# cat /etc/xinetd.d/tftp
# default: off
# description: The tftp server serves files using the trivial file transfer \
#       protocol.  The tftp protocol is often used to boot diskless \
#       workstations, download configuration files to network-aware printers, \
#       and to start the installation process for some operating systems.
service tftp
{
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -vvvvv -c -s /ipxe/
        disable                 = no
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}

NOTE: FOR DEBUGGING PURPOSES I HAVE DONE THE FOLLOWING: I have disabled the firewall:

[root@ipxe ~]# service iptables stop
iptables: Setting chains to policy ACCEPT: filter          [  OK  ]
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Unloading modules:                               [  OK  ]
[root@ipxe ~]# chkconfig iptables off

I have disabled SELinux because it sucks.

[root@ipxe tmp]# cat /etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

I have also rebooted a large number of times.

No matter what I seem to try, even changing CentOS version to 7 and repeating the process, the most I can get from tftp is:

Jan 30 22:52:01 ipxe xinetd[2013]: START: tftp pid=2265 from=192.168.10.186
Jan 30 22:52:01 ipxe in.tftpd[2266]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:06 ipxe in.tftpd[2267]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:11 ipxe in.tftpd[2268]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:20 ipxe in.tftpd[2269]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:25 ipxe in.tftpd[2270]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:30 ipxe in.tftpd[2271]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:35 ipxe in.tftpd[2272]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:40 ipxe in.tftpd[2275]: RRQ from 192.168.10.186 filename README

I can obviously ping the system and ssh into it and there seems to be no network issues of any kind that I can see.

What in heaven's name am I missing here? What is the next logical line in diagnosis of the issue? I'm almost ready to file a bug on the issue.

2
  • Dumb question perhaps, but is /ipxe/ the absolute path to the directory you want to get files from? Jan 31 '18 at 7:24
  • In the posted example. Yes. However I've tried it from the default /var/lib/tftpboot as well with the exact same results. Jan 31 '18 at 17:37
5

Turns out that when testing TFTP, you have to punch a hole through both the server AND the client's firewall. That doesn't make a lot of sense since most of the articles online will talk about selinux as well as disabling the firewall on the tftp server.

The server was working fine and even though I tried it from multiple different operating system types, from Windows to Linux to Mac, all 3 of those different tftp clients need to have a rule put into their firewall to allow access to tftp.

Normally, this is accompanied by a message in the tftp server which will say something to the tune of "No route to host", but that step was omitted for some reason.

If you were like me and are not sure what to do even though you have followed all of the direction. Make sure you punch a hole through the client's firewall as well.

3
  • "you have to punch a hole through both the server AND the client's firewall" : spot on
    – P Marecki
    Nov 14 '18 at 21:38
  • 1
    2020 and still has to work with this nonsense. spent the last 3 days to SELinux, ARP cache, IPTables and IPv6 issues just to make a TFTP server work for 2s to boot a PXE....
    – TecHunter
    Oct 12 '20 at 16:49
  • Maybe the TFTP conntrac helpers could help here?
    – NiKiZe
    Jul 29 at 15:06
1

The reason for this is that by default tftp listens on port 69, but starts file transfer on completely random ports, not processed by conntrack rule and therefore gets blocked by a firewall.

You can specify port range with -R xxxx:xxxx parameter at server_args in /etc/xinet.d/tftp:

server_args = -R 9990:9999 [rest of your parameters]

However this is a partial solution, as this can not be set to the same value as the listening port, and this will be a source port rather than destination port. Therefore you will most likely need a specific firewall rule on the client.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.