Description
This article discusses tracert/traceroute behavior over IPsec VPN tunnel:
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, 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 article, IP address 10.156.0.22 is incorrect, how FortiGate select the IP to respond and what is the workaround.
Solution
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:
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, the 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.
Via CLI method:
config system interface
edit "IPsec" <----- Name of the tunnel interface.
set ip 1.1.1.12 255.255.255.255
edit "IPsec" <----- Name of the tunnel interface.
set ip 1.1.1.12 255.255.255.255
set remote-ip 1.1.1.11 255.255.255.255
set interface "wan1"
next
end
set interface "wan1"
next
end
The tracert/traceroute result is shown after configured IP address on the 140D IPsec VPN interface.
