|
IPsec site-to-site VPN must have the 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 v7.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 diagnosed VPN like gateway list and diagnosed 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 did not offer a next-hop, the route for the 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 route.
Impact on Static Routes:
Due to this new change, only the following IPsec designs support the usage of static routes:
- Static-to-site IPsec tunnel + net-device enable/disable:
- FortiGate CLI automatically adds the gateway value to the route configuration.
- Dialup (dynamic) IPsec tunnel + net-device disable:
- The gateway configured for the route matches the correct tunnel ID.
- No gateway, but the destination IP (mode-cfg/client IP) matches the tunnel ID.
Note:
With this new behavior, net-device (Device Creation) only needs to be enabled if a site-to-site IPsec tunnel creates child tunnels because of the shortcut tunnel function of ADVPN (i.e. on ADVPN Spoke FortiGates). Since the site-to-site IPsec tunnel does not have the lookup function of dial-up, net-device needs to be enabled as part of the phase 1 setting; otherwise, the kernel cannot choose the correct outgoing interface (oif) for the shortcut tunnel specified by its tunnel ID.
Related articles:
Implement Hub and Spoke or point to multi... - Fortinet Community
ADVPN and shortcut paths | FortiGate / FortiOS 7.4.5 | Fortinet Document Library Technical Tip: IPsec VPN route shows a different gateway IP than a remote IP address
Technical Tip : IPsec Tunnel ID expected behavior
|
