FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
When advertising a static route to an iBGP neighbor, the next hop information of that static route is not changed to a FortiGate IP but to the one of the next hop in the static route definition.

This article describes this feature.

# config router bgp
    set as 65000
    set router-id
    # config neighbor
        edit ""
            set remote-as 65000
    # config network
        edit 1
            set prefix
    # config redistribute "static"
        set status enable

# config router static
    edit 4
        set dst
        set gateway                         
        set device "internal"
get router info bgp network                          <---- On the peer side.
BGP routing table entry for
Paths: (1 available, best 1, table Default-IP-Routing-Table)
  Not advertised to any peer
  Local from (
      Origin incomplete metric 0, localpref 100, valid, internal, best
      Last update: Tue Feb 4 02:25:22 2020
Advertising to a BGP peer by using both a network statement and redistribute static for a prefix which is also mentioned in a static route entry, the local BGP routing table will have 2 entries:
get router info bgp network
BGP table version is 2, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network                        Next Hop                       Metric    LocPrf   Weight RouteTag Path
*                                                100      32768     0              i <-/-> *>
 *>                                                                         32768     0              ? <-/1>
The first entry does not have a BGP NextHop because it is inserted into the BGP table due to the 'network' statement for

The second entry has a BGP next-hop because it is inserted into the BGP table due to the 'redistribute static' statement.
The redistribution process preserves the original next-hop from the source protocol (here, static route) as well as other original attributes (e.g., an OSPF cost would become a BGP MED).
The best of this two prefixes (the one with '>' which has a BGP NH) is announced to the peer via iBGP. Consequently, BGP NH is preserved when the prefix is advertised to the peer.
The spoke therefore sees the next-hop of the original static route.

If this behavior is not wanted, two options are proposed:

- Use only network statements for the static commands.
- Use a route map when redistributing static and change the next hop to an IP on the FortiGate.