TFTP Uses UDP 69—but the File Transfer Uses More Ports

A TFTP request can reach a server on UDP port 69 and still fail before the file arrives. The reason is that port 69 handles the initial request, while the file transfer then uses other UDP ports selected for that session.

That distinction matters when configuring a host firewall, router, or cloud security rule: allowing UDP 69 is necessary for the default service, but may not be sufficient for a complete transfer.

What happens during a TFTP transfer?

TFTP uses UDP, not TCP, for its standard operation. A client sends a read request (RRQ) or write request (WRQ) to the server's UDP 69 port. After receiving it, the server responds from a different UDP port, and the client and server use transfer-specific ports for the rest of the exchange.

For example, a client might send a request from UDP port 49152 to server port 69. The server might respond from UDP port 53000. Those numbers are illustrative; the actual transfer ports depend on the implementation and session.

The practical consequence: a firewall rule that permits traffic only to UDP 69 can let the request through but block the response or later data packets. This can look like a TFTP timeout even though the initial request reached the server.

Firewall rules: allow the request and the transfer

The initial request normally needs to reach the server on UDP 69. The remaining traffic must also pass in both directions on the ports used for that transfer.

Where supported and appropriate, a stateful firewall with TFTP-aware handling can track the protocol and allow the related traffic. Otherwise, check the TFTP server's documentation for whether it supports a configurable transfer-port range, then permit only the documented range needed for your setup.

There is no universal extra UDP range that applies to every TFTP server. The exact rules depend on the server, firewall, NAT devices, and network path. Avoid opening a broad UDP range based on guesswork, and restrict rules to the necessary hosts or network where possible.

For more on how host, router, and cloud firewall rules fit together, see this guide to opening ports across common firewall layers.

Allow the initial request with UFW

On a Linux host using UFW, this permits incoming UDP traffic to port 69:

sudo ufw allow 69/udp

This creates a rule for the initial service port; it does not by itself configure or guarantee passage of the transfer traffic. Configure that separately according to your server and firewall setup.

Allow the initial request with Windows Firewall

In an elevated PowerShell session, you can create an inbound rule for UDP 69:

New-NetFirewallRule -DisplayName "TFTP UDP 69" -Direction Inbound -Protocol UDP -LocalPort 69 -Action Allow

This opens UDP 69 on the local Windows firewall only. It does not set up a transfer-port range or a TFTP-aware firewall helper. Apply the additional transfer rules your network requires, and avoid enabling the rule on network profiles where the service should not be reachable.

Troubleshoot the whole packet path

If the request appears to reach the server but a transfer stalls, check more than the rule for port 69:

1. Confirm the TFTP server is running and configured to listen on the expected service port.
2. Check that the initial request reaches the server. The default destination is UDP 69, unless the service is configured to use another port.
3. Inspect the transfer traffic. Look for the UDP ports selected after the request and check whether firewall rules allow them.
4. Check every firewall and NAT layer. The server's local firewall may allow traffic while a router or cloud firewall blocks it.
5. Capture UDP packets between the client and server. Include the negotiated ports, not just port 69.

On Linux, a broad capture can show UDP packets on available interfaces:

sudo tcpdump -ni any udp

In a busy environment, narrow the capture by client or server address while keeping the filter broad enough to include the transfer ports. A filter that matches only UDP 69 can show the initial request while missing the rest of the exchange. If you're capturing on Windows, these packet-capture options and examples can help you inspect traffic.

Can TFTP use a different port?

Some TFTP clients and servers let you configure the listening port, but support and settings vary. If you change the server's port, the client must send its initial request to that port too. Check the documentation for both ends before changing the default.

Changing the listening port does not make the entire transfer stay on that port. The transfer still uses session-specific UDP ports, so firewall and NAT rules must account for that behavior.

The key distinction

TFTP's standard service port is UDP 69. It carries the initial read or write request; subsequent packets use transfer-specific UDP ports. When a transfer stalls, verify that the service is running, then inspect the full UDP exchange and every firewall or NAT layer in its path. Don't assume that allowing UDP 69 alone is enough.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.