FortiGate
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.
MJ_FTNT
Staff
Staff
Article Id 254175
Description This article describes the behavioral change with regards to IPsec tunnel interface IP address and routing starting from FortiOS 7.0, as well as its impact on OSPF neighborship.
Scope FortiOS 7.0+.
Solution

IPsec site-to-site VPN must have tunnel interface IP addresses assigned to run routing protocols like OSPF. When defining the tunnel interface IP address as follows...

 

# config system interface
    edit "OSPF"
        set vdom "root"
        set ip 10.251.251.2 255.255.255.255
        set allowaccess ping
        set type tunnel
        set remote-ip 10.251.251.1 255.255.255.255
        set snmp-index 21
        set interface "port2"
    next
end

 

... This can be seen on the FortiGate under the results of ‘diag ip add list’:

 

IP=10.251.251.2->10.251.251.2/255.255.255.255 index=50 devname=OSPF

 

As seen above, there is no remote IP address in the address pair.

As of FortiOS version 7.0+, FortiOS uses a special static route to reach the remote-ip of the tunnel instead of using an IP address pair.

 

With the new IPsec kernel design, the route tree is not available in the IPsec tunnel list used to select tunnels by the next hop. A tunnel ID is automatically generated and used to link routes with the IPsec tunnel. The IPsec tunnel ID is normally the remote gateway of the tunnel. For tunnels with the same remote gateway, the tunnel ID is randomly assigned (10.0.0.x) and will be different from the remote gateway. The tunnel ID (tun_id) is visible when running diagnose VPN ike gateway list and diagnose VPN tunnel list.

 

With the new design, there is a change in the next-hop of the route as IPSec tunnel-id. Since the default connected route didn't offer a next-hop, the route for remote tunnel interface IP is modified as the static route.

 

A route also has a tunnel ID, which coincides with the route gateway. When a route directs traffic to an IPsec interface and there are multiple VPN connections (usually dialup VPNs): if they have the same remote gateway, then the tunnel ID is automatically assigned.

Note that the route next hop of an IPsec VPN tunnel is only a tunnel identifier and is not the real route next hop IP, which is different than the ordinary route next hop.

 

With the interface configuration, there is a static route added automatically with the remote tunnel IP interface and subnet as seen below:

 

S 10.251.251.1/32 [5/0] via OSPF tunnel 192.168.60.1, [1/0]
C 10.251.251.2/32 is directly connected, OSPF

 

If the remote-IP subnet is anything except /32 when configuring OSPF on an IPsec tunnel, it is important to keep this special static route active in the routing table for OSPF neighborship to establish. Otherwise, there will be a mismatch with the neighbor interface subnet as shown below:

 

OSPF: RECV[Hello]: source 10.251.251.1/32 does not match interface OSPF

 

It is also recommended to use the /32 subnet for the remote end when using OSPF since the static route will be for the /32 remote subnet, which will be preferable to any other routes.