TFTP issues with NAT - External TFTP traffic not being passed to client

[BazMonkey]

A LAN client is trying to copy a file from an externally hosted TFTP server on UDP 69.Server is 3.xxx.xxx.xxx

We are seeing traffic on the LAN side making a outgoing connection to the server 3.xxx.xxx.xxx. We are seeing a reply from the server on the internet side but this traffic is not being seen on the LAN side.

LAN side capture showing outgoing request to TFTP internet hosted TFTP server on UDP 69
Client is sending it's ephemeral port shown below as 57357/8 on this capture.

59.xx.xx.x is the external facing WAN 1 IP.

03:27:26.814127 IP 10.xxx.xxx.xxx.57357 3.xxx.xxx.xxx.69: 47 RRQ "filename.bin" octet
03:27:37.813805 IP 10.xxx.xxx.xxx.57357 3.xxx.xxx.xxx.69: 47 RRQ "filename.bin" octet
03:27:48.814127 IP 10.xxx.xxx.xxx.57357 3.xxx.xxx.xxx.69: 47 RRQ "filename.bin" octet

WAN side capture. As you can see the TFTP server is replying with 57357 as the destination UDP port which seems OK.

03:28:23.321187 IP 3.xxx.xxx.xxx.40000 59.xx.xx.xx.57358: UDP, length 516
03:28:26.082806 IP 3.xxx.xxx.xxx.40001 59.xx.xx.xx.57357: UDP, length 26
03:28:27.087741 IP 3.xxx.xxx.xxx.40002 59.xx.xx.xx.57357: UDP, length 516
03:28:28.072184 IP 3.xxx.xxx.xxx.40003 59.xx.xx.xx.57357: UDP, length 516
03:28:28.335387 IP 3.xxx.xxx.xxx.40000 59.xx.xx.xx.57358: UDP, length 516
03:28:31.079360 IP 59.xx.xx.xx.57358 3.xxx.xxx.xxx.69: 47 RRQ "filename.bin" octet
03:28:31.317015 IP 3.xxx.xxx.xxx.40001 59.xx.xx.xx.57358: UDP, length 516
03:28:34.325215 IP 3.xxx.xxx.xxx.40001 59.xx.xx.xx.57358: UDP, length 516
03:28:37.093729 IP 3.xxx.xxx.xxx.40002 59.xx.xx.xx.57357: UDP, length 26
03:28:38.133726 IP 3.xxx.xxx.xxx.40003 59.xx.xx.xx.57357: UDP, length 516
03:28:38.344658 IP 3.xxx.xxx.xxx.40000 59.xx.xx.xx.57358: UDP, length 516

I rasied a TAC case as my understanding is that the MX should not block this traffic and just forward it on to the orignating client.

My reply from Meraki TAC

===================

The problem is at the UDP port numbers 40000, 40001, 40002, 40003 from the TFTP server 3.xxx.xxx.xxx.
The MX has the flow for UDP port 69 to the TFTP server and it does not have an egress flow for UDP port 4000* to the TFTP server.

As the nature of the firewall, the MX just drops the unmatched packets.
The MX has NAT'ed properly for the outgoing traffic and the TFTP server has received the packets and replied back.

===================

Is my understanding of MX's functions wrong. Why would I need to port forward 4000x in the MX.

I never see a single  packet from 3.xxx.xxx.xxx appear on the LAN side.

Cheers
Barry

[Brash · Accepted solution]

TFTP is not a great protocol for over-the-internet transfers.
You're much better off using FTP (or even better, SFTP)

TFTP uses port UDP 69 for initial contact.

However, the transfer itself takes place completely on ephemeral ports.

From the packet flows provided, we see the initial communication from LAN client to WAN server with destination port UDP 69, and source port of 57357.

We then see the TFTP server respond with an ephemeral source port of its choosing (in this case 40000) and destination port 57357 for the initial communication and transfer setup. This is expected as per the RFC.

As this flow from server to client does not match the stateful flow that the MX has seen (as its expecting to see a source port of 69), the packets are dropped as expected.

If you want to do some advanced reading, check out RFC 1350: The TFTP Protocol (Revision 2) (rfc-editor.org)
Specifically, section 4 - Initial Connection Protocol.

[AlexP]

I will also chime in here and say that, historically vendors have worked around this with "NAT fixups" for protocols like this that predate mass deployments of NAT (yes, TFTP is that old...) which do payload inspections, and put the appropriate NAT mappings into place based on that, but it's not something we support.

SFTP is the way to go here, if not just because it tunnels everything over SSH to avoid this problem, but to also avoid transmitting your username and password in cleartext over the internet, like you'd be doing with (T)FTP.

[BazMonkey]

Cheers for the reply

I'm stuck with a vendor using TFTP right now as their device is only coded for TFTP (Quite old device)

I'm going run a local TFTP server to get around this problem as it's only a one off problem for now.