Description
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.
SolutionTracert/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:-
if=lo family=00 type=772 index=1 mtu=16436 link=0
master=0
ref=4 state=present fw_flags=0 flags=loopback
if=eth0 family=00 type=1 index=2 mtu=1508 link=0
master=0
ref=3 state=start present fw_flags=0 flags=up broadcast run
promsic multicast
if=mgmt family=00 type=1 index=3 phyindex=4 mtu=1500 link=0
master=0
ref=3 state=start present tx_sched fw_flags=0 flags=up
broadcast promsic allmulti multicast
if=ha family=00 type=1 index=4 phyindex=2 mtu=1500 link=0
master=0
ref=8 state=start present fw_flags=0 flags=up broadcast run
promsic allmulti multicast
if=port1 family=00 type=1 index=5 phyindex=5 mtu=1500 link=0
master=0
ref=2 state=start present tx_sched fw_flags=0 flags=up
broadcast promsic allmulti multicast
if=port2 family=00 type=1 index=6 phyindex=16 mtu=1500 link=0
master=0
ref=1 state=start present tx_sched fw_flags=0 flags=up
broadcast multicast
if=port3 family=00 type=1 index=7 phyindex=27 mtu=1500 link=0
master=0
ref=19 state=start present fw_flags=0 flags=up broadcast run
promsic allmulti multicast
if=port4 family=00 type=1 index=8 phyindex=35 mtu=1500 link=0
master=0
ref=1 state=start present tx_sched fw_flags=0 flags=up
broadcast multicast
.
.
.
if=lan family=00 type=1 index=61 phyindex=3 mtu=1500 link=0
master=0
ref=9 state=start present fw_flags=0 flags=up broadcast run
promsic multicast
From the above command, we can see mgmt interface is the
lowest index interface with IP address configured. Therefore, it
will use it 192.168.1.99 to reply the TTL expired packet.
Instead of depending on the index number, you can configure an
IP address on the 140D IPsec VPN interface instead so that the
tracert/traceroute is showing expected IP address.
The tracert/traceroute result is shown after configured IP
address on the 140D IPsec VPN interface.