Skip to main content
R
RVTim10
Visitor II
May 14, 2026
Solved

TFTP Firmware Recovery issues with some recent Fortigate Firmware

  • May 14, 2026
  • 6 replies
  • 176 views

I have recently opened a ticket with Fortinet and shared this information so that Fortinet can fix a problem that was recently introduced in some of the newer 7.4 versions (such as 7.4.10, 7.4.11 and possibly earlier and later versions).  It may affect many other versions, but I'm not sure, because I've been only having the issues with recent 7.4 versions.  

I have tested this on models 40F, 60F, and 61F, but I am guessing it will not be model specific.

The issue: 

When doing a system Format of the drive, and then doing a TFTP firmware recovery, the TFTP connection will repeatedly "Timeout" when it attempts to download the firmware.   On the TFTP server side, there will be a log entry when it connects, and it will result in a "Transfer Timed Out" message after it tries a number of times.


I tested this using multiple TFTP servers:
1) TFTPD32/TFTPD64.exe by Philippe Jounin on windows. 
2) Fedora Linux's install of TFTP server
3) The "Transfer" app for Mac by intuitbits
4) Mac OS Native TFTP server
5) Mac OS "tftp-hpa" available by Homebrew, or MacPorts.

The TFTP transfer will not work with any of these softwares using default settings.   I have identified the issue:   In recent versions of Fortigate bootloader, it's trying to negotiate TFTP Option timeout=5, and TFTP Option blksize=1468.
It must be doing something wrong with the negotiation.

I was able to work around the issue with the following things.  In one case, I wrote to the software developer and he added a feature to his software specifically to fix the issue cased by Fortinet's programming.

1) On Tftpd64 by Ph. Jounin, you must go into tftp settings, and uncheck the box labeled "Option negotiation".   This will allow the transfer to complete. 

2) On Fedora's TFTP server, you must add these "--refuse" lines to the server config: (I did not try only using --refuse blksize).

[Service]
ExecStart=/usr/sbin/in.tftpd -c -p -s \
        --refuse blksize \
        --refuse tsize \
        --refuse timeout \
        /var/lib/tftpboot

3) On the "Transfer" app for Mac OS, I worked with the software developer, and he released a new version with 4 check boxes, which I tested.  The settings are Accept Options:  and 4 check boxes.   Timeout, Block Size, Transfer Size, and Block Number Rollover.    When I uncheck the box for "Block Size" the transfer will work.  Logging shows that the server then Rejects TFTP option blocksize request from Fortigate, and uses the default value of 512, rather than the value of 1468 that Fortigate is trying to use. Version 2.4.3 (31) is my current version that was the first release with this ability.  It's great software, so support the dev if you use a mac, and try it.

4) Mac OS Native TFTP server does not have the ability to adjust option negotiation, and therefore fails.  No fix available.

5) Mac OS "tftp-hpa" 3rd party tftp server DOES has --reject options similar to the linux fix in #2, and when you set up the --reject options, you can run the tftp server and transfer firmware successfully.

Hopefully this helps anyone that runs into this problem, as it took a few hours of head scratching to figure out what the issue was.

Best answer by RVTim10

I re-tested this and indeed it’s MTU related.  If you’re running across a VPN, or on a network with <1500 MTU, or a network adapter with an MTU <1500, tftp recovery may not work unless you have a tftp server capable of disabling option negotiation, where it will then default to 512 byte packets.

6 replies

Toshi_Esumi
SuperUser
Toshi_Esumi
SuperUser
May 14, 2026

If it fails at boot loader menu, the fortiOS isn’t loaded to RAM yet. So it shouldn’t make any difference what version of FortiOS image in your boot partition of the flash memory. Are you sure the problem doesn’t happen when you downgrade the image to like 7.4.9 then try loading up 7.4.11 or 7.4.12 again over TFTP?

Toshi  

R
RVTim10Author
Visitor II
May 14, 2026

I do get the boot loader, and I’m able to configure all the tftp parameters and run through the menus and start the

TFTP download process.   It’s just that the tftp download times out repeatedly, and fails.   This is after doing a “Format” in the boot menu, to completely format the drives, leaving it with no OS.  So this problem is strictly a tftp transfer issue and it is definitely related to the tftp options negotiation for block size.   I can’t say exactly when this started to be an issue, but I noticed it sometime between 3rd Q 2025 and present. 

I have not tried to downgrade to earlier OS versions such as 7.4.9 and try it.  I’m not sure if those would modify the pre-boot functionality available for TFTP download.  If it does re-flash that environment, perhaps it would.
but I do know that it affects recent versions for the 40F, 60F, and 61E models.

The real question, I guess, is when did they modify the pre-boot OS that allows recovery of the system via TFTP?  It was never a problem to format the disk and re-load via TFTP until recently, so something changed.  And the fact that it didn’t work with tftp servers that in the past had worked, and is broken on 5 different ones, unless you change settings, points the issue squarely at something that Fortinet changed to that pre-boot environment.

T

Toshi_Esumi
SuperUser
Toshi_Esumi
SuperUser
May 14, 2026

What I’m saying is it’s must be the boot rom software. Nothing to do with FortiOS if everything you’re saying is true. So the model might matter.

Toshi

R
RVTim10Author
Visitor II
May 14, 2026

Ahh sure.  Makes perfect sense!  My thought was that maybe the boot ROM got upgraded during a FortiOS upgrade, but I’m not sure if that’s a thing.  Not sure why this problem only started recently within the last year.

The one thing that I can think of that could be a factor is, is the TFTP server remote, via VPN, in which case it could be that the TFTP request has the df bit set, and the MTU is too large at 1468 to make it.  But I’d think it shouldn’t have the df bit set.

 

Toshi_Esumi
SuperUser
Toshi_Esumi
SuperUser
May 14, 2026

Just for the record. I just rebooted my lab FG60F w/ 7.4.12 then flushed boot drive, then uploaded the 7.4.12 image from Tftpd64 running on my laptop, which is directly connected to WAN1 port. It went through without any problem.
After reloading the backed up config, it’s working as it was before.
So the problem is more likely bound to your particular network environment.

Toshi

    R
    RVTim10Author
    Visitor II
    May 14, 2026

    Thanks for that.  Re-thinking the MTU, if they indeed have the df bit set, that could be a problem.  At least the thread is here so that people see workarounds.  

    R
    RVTim10AuthorAnswer
    Visitor II
    May 18, 2026

    I re-tested this and indeed it’s MTU related.  If you’re running across a VPN, or on a network with <1500 MTU, or a network adapter with an MTU <1500, tftp recovery may not work unless you have a tftp server capable of disabling option negotiation, where it will then default to 512 byte packets.

    Terms & ConditionsAccessibility statement