Troubleshooting Tip: The remote IP address of the IPsec interface does not appear in the routing table

[jdelafuente_FTNT]

Description

This article describes how to solve the routing problem when the IPSec interface is configured with local and remote IP addresses but the remote IP is not loaded in the routing table.

Scope

FortiGate, VPN IPSec, SD-WAN, BGP, SLA, FIB, routing table.

Solution

Possible behavior:

• The SLA does not start, probe packets are not sent from FortiGate.
• IPSec VPN is up but traffic is not forwarded over the tunnel due to no active route in the routing table.
• If the remote IP is a BGP Neighbor, dynamic routing never established.   

IPSec interface configuration:

config system interface

    edit "VPN_Central"

        set vdom "root"
        set ip 10.254.254.2 255.255.255.255
        set allowaccess ping
        set type tunnel
        set remote-ip 10.254.254.1 255.255.255.255 <----- Remote IP 10.254.254.1.
        set interface "port1"

    next

end

Route lookup does not show the route for the remote tunnel IP:

get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
* - candidate default

Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via 10.2.2.254, port1, [1/0]
C 10.2.2.0/24 is directly connected, port1
C 10.254.254.2/32 is directly connected, VPN_Central <----- No valid route for remote IP 10.254.254.1 or network.
C 192.168.201.0/24 is directly connected, port2

Route database includes IPSec remote IP and remote networks, but not in FIB:

get router info routing-table database
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
V - BGP VPNv4
> - selected route, * - FIB route, p - stale info

Routing table for VRF=0
S *> 0.0.0.0/0 [10/0] via 10.2.2.254, port1, [1/0]
C *> 10.2.2.0/24 is directly connected, port1
S > 10.254.254.1/32 [5/0] via VPN_Central tunnel 10.1.1.1, [1/0]
C *> 10.254.254.2/32 is directly connected, VPN_Central
S > 172.16.10.0/24 [10/0] via VPN_Central tunnel 10.1.1.1, [1/0]
C *> 192.168.201.0/24 is directly connected, port2

SLA is Dead and no probe attempts in the sniffer packet:

diagnose sys sdwan health-check status
Health Check(SLA_Central):
Seq(5 VPN_Central): state(dead), packet-loss(100.000%) sla_map=0x0

diagnose sniffer packet any 'host 10.254.254.2' 4 0 l
Using Original Sniffing Mode
interfaces=[any]
filters=[host 10.254.254.2]

VPN phase-1 configuration:

config vpn ipsec phase1-interfa

    edit "VPN_Central"

        set interface "port1"
        set ike-version 2
        set peertype any
        set proposal aes256-sha256
        set dhgrp 14
        set nattraversal disable
        set remote-gw 10.1.1.1 <-- Remote peer IP.
        set psksecret ENC **removed**

    next

end

Misconfiguration in VIP using remote peer IP with ARP enabled:

config firewall vip

    edit "NAT-Central"

        set extip 10.1.1.1 <-- Remote peer IP used as ext IP.
        set mappedip "192.168.50.18"
        set extintf "any"
        set arp-reply enable
        set portforward enable
        set extport 443
        set mappedport 443

    next

end

Solution:

Delete VIP or disable arp-reply and then renegotiate VPN. 

Results:

The IP and the remote network in route table (fib), SLA works, and sniffer packet show requests and replies for ICMP probes:

get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
* - candidate default

Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via 10.2.2.254, port1, [1/0]
C 10.2.2.0/24 is directly connected, port1
S 10.254.254.1/32 [5/0] via VPN_Central tunnel 10.1.1.1, [1/0]
C 10.254.254.2/32 is directly connected, VPN_Central
S 172.16.10.0/24 [10/0] via VPN_Central tunnel 10.1.1.1, [1/0]
C 192.168.201.0/24 is directly connected, port2

diagnose sys sdwan health-check status
Health Check(SLA_Central):
Seq(5 VPN_Central): state(alive), packet-loss(0.000%) latency(2.132), jitter(1.266)...

diagnose sniffer packet any 'host 10.254.254.2' 4 0 l
Using Original Sniffing Mode
interfaces=[any]
filters=[host 10.254.254.2]
2025-04-09 11:40:45.612146 VPN_Central out 10.254.254.2 -> 10.254.254.1: icmp: echo request
2025-04-09 11:40:45.612173 VPN_Central in 10.254.254.1 -> 10.254.254.2: icmp: echo reply
2025-04-09 11:40:45.612191 VPN_Central out 10.254.254.2 -> 10.254.254.1: icmp: echo request
2025-04-09 11:40:45.612417 VPN_Central in 10.254.254.1 -> 10.254.254.2: icmp: echo reply

Related article:

Technical Tip: IP pool and virtual IP behavior changes in FortiOS 6.4, 7.0, 7.2, and 7.4