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.
Referring to the diagram above, if tracert/traceroute is performed
on PC at 192.168.20.99 to PC at 10.156.0.202 across IPsec VPN
tunnel, we may get output as below:-
The issue is 192.168.1.99 is a "mgmt" interface, the interface
is not connected at all. From logical point of view, it should be
showing IP address 10.156.0.22 since the packet went out through
this interface, but this is incorrect. In this KB, we will discuss
why IP address 10.156.0.22 is incorrect, how FortiGate select the
IP to respond and what is the workaround.
Tracert/traceroute packet is based on increment of TTL value
for each hop the packet traversing. It will start off with TTL
value = 1, the first packet will reach 192.168.20.1. Since the TTL
is already expired, FortiGate will not perform any routing table
lookup to see which interface or next hop to send the packet out.
Therefore, FortiGate will use 192.168.20.1 to respond the
tracert/traceroute packet and not 10.125.0.21.
The problem arise when the traceroute is traversing through
IPsec VPN tunnel, in which IPsec VPN tunnel interface is a logical
interface and often, we do not configured any IP address on that
interface. Therefore in this case, FortiGate respond with IP
address of 192.168.1.99. This is an IP address of mgmt interface
and the interface is not even up nor connected with any cable. How
do FortiGate decide to select which IP address to respond?
FortiGate will use the IP address of the interface starting from
lowest index value. Index value can be found from the command
"diagnose netlink interface list".
Below is the partial output of command "diagnose netlink
interface list" in FortiGate 140D:-