0

I have a piece of hardware which I am attempting to PXE boot. Currently, it PXE boots, DHCP leases TCP/IP data to the end-point and then it goes to its "next-server" to TFTP over some iPXE firmware.

It gets to the point where it establishes a TFTP connection over port 69 and begins to try and transfer the firmware over. This is where I'm having an issue, because the "return" ports it is attempting is blocked by our corporate firewall.

Here is a netstat taken at that exact moment on the TFTP server:

# netstat -tunap | grep tftp
udp        0      0 10.254.52.26:45140      10.55.32.175:2073       ESTABLISHED 25115/in.tftpd
udp        0      0 10.254.52.26:53684      10.55.32.175:2072       ESTABLISHED 25108/in.tftpd

It seems to always try either ports 2073 and 2072 on the end-point. Very consistent.

However, if I load the OS from the disk on that same end-point and use a TFTP client to connect (atftp in this case), it makes the connection and downloads no issue. Here is the netstat of that:

# netstat -tunap | grep tftp
udp        0      0 10.254.52.26:50986      10.55.32.175:44669      ESTABLISHED 26500/in.tftpd
udp        0      0 10.254.52.26:54390      10.55.32.175:44669      ESTABLISHED 26484/in.tftpd

In this case, it uses port numbers generally above 40000, which is allowed by our firewall. This is also very consistent.

I can request to have some additional ports opened up, however I really would like to understand why it behaves like this. Does this have something to do with the client? That is the only thing that seems to be changing in this scenario (PXE client firmware vs. atftp client on OS).

Any understanding someone could offer would be much appreciated.

azurepancake
  • 141
  • 1
  • 8
  • Depending on the firewall, it may be possible to allow TFTP traffic through by analyzing the initial packets where the port numbers are negotiated. Linux iptables can do this, and I'd expect commercial firewalls to have a similar feature, given that IP phones often load configuration over TFTP. – Simon Richter Feb 08 '21 at 14:02

2 Answers2

2

TFTP is defined in RFC 1350. Similar to FTP, just the first contact and command exchange uses UDP port 69 on the server side. All further transfers use ephemeral ports (which may differ considerably, depending on platform). These may be predicted for known PXE clients but there's no rule, generally...

So, unless you are able to permit related UDP "connections" on the firewall you likely need to permit all UDP transfers to/from the PXE server. And really, firewalls work a lot better if you permit what you need and then leave everything else denied.

Community
  • 1
Zac67
  • 10,320
  • 2
  • 12
  • 32
  • Is it likely possible that the TFTP client built into the hardware's PXE firmware is requesting a specific source port (207X)? Other hardware PXE clients seem to always get a high ephemeral port, but these low ports seems to be unique to this hardware. – azurepancake Feb 05 '21 at 15:38
  • The PXE firmware has its own stack - since it runs always in the same way it might use the same port each time (which isn't too clever actually, for security reasons). Other stacks may use explicit randomization. Note that IANA's recommendations for ephemeral port ranges have changed over time and now use 49152-65535. Old recommendations started as low as 1025. – Zac67 Feb 05 '21 at 15:46
1

RFC 1350 4. Initial Connection Protocol

Clearly explains how the ephemeral ports are chosen by the client and the server.

Community
  • 1
Pat
  • 3,519
  • 2
  • 17
  • 17