The server says Running, the switch says timeout, and nothing arrives. Nine times out of ten the silent middleman is Windows Firewall. Here is the correct rule — UDP, port 69, Private profile only — plus how to prove the server is really listening before you blame the network.
TFTP fails quietly. There is no friendly error on the PC; the device just retries and reports a timeout. Because the server 'looks' started, people go hunting through cables and device settings — when the real answer is that Windows Firewall dropped the inbound UDP packet and told nobody. This guide adds the rule properly, explains the one behaviour of TFTP that confuses even experienced admins (the reply comes from a different port), and gives you two quick proofs that separate a firewall problem from a network problem.
Before touching the firewall, prove the server exists. On the PC, open Command Prompt and run:
netstat -an | findstr :69UDP ... :69 line means the tool has bound the port. Note the address: 0.0.0.0 means all adapters; a specific IP means it listens only there — make sure that IP is the LAN adapter the device can reachIf the first-run popup was dismissed or clicked away, add the rule manually:
69TFTP Server UDP 69, so future-you knows why it existsAlternatively, a rule for the program itself (allow the tool's .exe inbound) achieves the same on a single LAN and is what the first-run popup creates.
Here is the part that makes TFTP look firewall-cursed. The device sends its request to UDP 69 — but the server then answers from a new, temporary port, and the whole transfer flows on that port pair. Windows Firewall understands this conversation for a directly-connected LAN, so the single inbound rule above is enough. Trouble starts with stateful firewalls between subnets, NAT devices, and strict "allow only port 69" rules written by hand — they see the reply as an unrelated new conversation and drop it. If your device sits across such a firewall, the practical fixes are: put the TFTP PC on the device's subnet for the job, or have the network team add a proper TFTP-aware rule. No setting inside the TFTP tool changes this protocol behaviour.
Every GUI TFTP tool shows a log pane. Start a transfer and watch it:
That single glance splits every TFTP problem cleanly in half: network side or server side.
Disabling Windows Firewall to make a transfer work trades a five-minute rule for an unprotected PC — and if it "works", people leave it off. If you ever test with the firewall paused, treat it strictly as a 60-second diagnostic to prove the diagnosis, then turn it back on and add the proper rule. A named, Private-only UDP 69 rule is the professional end state; you can even disable that rule between jobs for an extra layer of tidiness.
With a listening server and a correct rule, check the unglamorous rest: third-party antivirus firewalls that override Windows Firewall; the PC being on the Public network profile (Windows then ignores your Private rule — check the network's profile in Settings); the device and PC on different VLANs with no route; and a second TFTP tool or service already holding port 69. Work down the list; one of them is always the answer.
The full TFTP server setup — installation, root folder, firewall and a live transfer — is shown step by step in the video.
▶️ Watch Full VideoOn the Windows PC, no. Windows Firewall allows outbound traffic by default, and the server's replies are part of the conversation the inbound rule started. Hand-built rules are needed only when the path crosses a separate stateful firewall between subnets — that is a network-team change, not a PC setting.
Run the two proofs in this guide. If netstat shows nothing on port 69, the tool is not bound — restart it as administrator. If the tool's log stays empty during a transfer, look at the network profile (Public blocks Private rules), a third-party firewall, or the device using the wrong server address. If the log shows requests, your problem is file-side, not firewall-side.
The rule only matters while a TFTP server is actually running and listening. With the tool closed, the open rule reaches nothing. Good practice is still to stop the server after each job; tidier practice is to disable the rule between jobs as well. What you must not do is disable the whole firewall instead of managing one small rule.