Strange Problem when Trying to TFTP my config.

Unanswered Question
May 7th, 2008


I wasn't sure where to post this so forgive me if this is the wrong spot.

I have a script that automatically TFTP's my configs to a server. For some reason it stop working. I tried to to it manually and it times out. It updtes the time stamp of the file in the /tftpboot dir. But it never buts the config out there. I was thinking this was a firewall problem but from what I can tell the firewall seems to be fine. I have no errors on my firewall (watch guard). I even ran policy checker and it allows tftp through. I ran wireshark and this is what I see:

I see the write request, file: abc.bkup\000, transfer type: octet\000

acknowledement, Block 0

acknowledgement, Block 0

Data Packet, Block: 1

then the next line in wireshark is ICMP

Destination unreachable (port unreachable)

This ICMP packet is the same source and dest as my TFTP transfer is. From the router I can ping the TFTP server with not issues.

Thanks in advance for the help


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Jon Marshall Wed, 05/07/2008 - 11:27


Port unreachable suggests there is a problem with the actual tftp service/daemon on your server even though you say the timestamp is getting updated.

Could you stop and restart the tftp server and try again.

Is your tftp server a unix or windows box ?. Is there enough space on device you are writing to ?


MICHAEL CICCONE Wed, 05/07/2008 - 12:21


I've tried both windows and LINUX/UNIX. I haven't tried restarting TFTP deamon. But other servers (not behind the firewall) work fine. I think its the firewall but, everything checks out ok on the firewall.

michael.leblanc Thu, 05/08/2008 - 15:27

You've not been clear about which packet is from which device, or which device responded with the "port unreachable" ICMP message.

You also haven't indicated on which side of the firewall the trace was captured.

Posting a summary of the trace might be helpful.

Typically, the client sends the write request to the server (udp src port >1023 TO udp dst port 69).

However, the data transfer is "initiated" by the server, in a different channel (udp src port >1023 TO udp dst port >1023).

The firewall needs to accommodate this inbound connection "initiation".

In the absence of "inspection", your ACLs would need to provision the "return path" through the firewall.

I think you need to take a closer look at the trace file.


This Discussion