| Description |
This article describes a known issue that can occur when a dial-up IPsec tunnel ID changes while using OSPF for dynamic routing. In this scenario, the tunnel ID for the VPN tunnel changes (as per diagnose vpn ike gateway list), but the tunnel ID associated with the OSPF route does not change (as per the routing table entry). |
| Scope | FortiOS 7.4, 7.6. |
| Solution |
Consider the following example topology, where the FortiGate is acting as a dial-up IPsec server/hub and is using OSPF for dynamic route sharing to/from connected dial-up IPsec clients:
As a primer, FortiOS 7.0 and later introduced the concept of 'tunnel IDs' for dial-up IPsec tunnel interfaces. This tunnel ID is either set to the remote gateway IP address of the peer (e.g., the public IP of 160.223.165.3 for the example dial-up client given above) OR it is assigned a random tunnel ID in the 10.0.0.x range if there is already an existing device with the same public IP as the tunnel ID. For more info, see the following article: Technical Tip: Change in behavior of IPsec tunnel interface IP address and routing on FortiOS v7.x.
Trigger condition: When the dial-up Spoke has to re-establish the IPsec tunnel (such as when the dial-up client changes its public IP or if the tunnel flaps for some reason), then it is possible for a new, different tunnel ID to become associated with that Spoke on the FortiGate dial-up hub. However, while the IPsec tunnel connection uses the new tunnel ID, OSPF peerings will not automatically update to use the new tunnel ID since the inactivity timer has not yet expired.
When this occurs, traffic forwarding from the FortiGate hub to the dial-up Spoke stops functioning correctly, though traffic in the Spoke -> FortiGate direction does continue to work.
The reason that this traffic issue occurs is because the tunnel ID shown in the IKE gateway list (diagnose vpn ike gateway list) must match the tunnel ID of the OSPF interface and its associated routes in the routing table (get router info routing-table all). If they mismatch (such as one showing the Public IP of the Spoke and the other showing a dynamic 10.0.0.x ID value) then traffic will not be able to use those routes successfully.
Example:
When working, the tunnel ID in the routing table matches the tunnel ID of that associated tunnel in the IKE gateway list:
FortiGate # get router info routing-table details 10.20.3.3 Routing table for VRF=0 Routing entry for 10.20.3.0/24 Known via "ospf", distance 110, metric 20, best Last update 00:05:15 ago * via Dialup_0 tunnel 10.0.0.12 vrf 0 <-----
FortiGate # diagnose vpn ike gateway list vd: root/0 name: Dialup_0 version: 2 interface: wan1 17 addr: 96.48.132.206:4500 -> 160.223.165.3:2046 tun_id: 10.0.0.12/::10.0.0.14 <----- remote_location: 0.0.0.0 network-id: 0 transport: UDP virtual-interface-addr: 192.168.10.1 -> 192.168.10.2 created: 350s ago peer-id: FTNT
In the non-working scenario, the Spoke's IP address may have changed or some other event occurs that triggers a tunnel flap. As a result, the IPsec tunnel is re-established but a new tunnel ID has been assigned. In this example, the tunnel ID displayed in IKE gateway list becomes the Spoke's remote gateway address (i.e., the public IP), whereas the tunnel ID shown in the routing table's OSPF routes remains the 10.0.0.x ID:
Routing table for VRF=0 Routing entry for 10.20.3.0/24 Known via "ospf", distance 110, metric 20, best Last update 00:05:50 ago * via Dialup_0 tunnel 10.0.0.12 vrf 0 <----- Tunnel ID remains the same as before...
Fortigate # diag vpn ike gateway list 96.48.132.206 vd: root/0 name: Dialup_0 version: 2 interface: wan1 17 addr: 96.48.132.206:4500 -> 160.223.165.3:2046 tun_id: 160.223.165.3/::10.0.0.14 <----- But the IPsec Tunnel ID has actually changed. remote_location: 0.0.0.0 network-id: 0 transport: UDP virtual-interface-addr: 192.168.10.1 -> 192.168.10.2 created: 10s ago peer-id: FTNT
Tunnel ID in routing-table: 10.0.0.12
Workaround:
As a workaround, restart the OSPF routing process by running the command execute router clear ospf process. This forces the OSPF process to utilize the new tunnel ID value associated with that Spoke FortiGate, though it does require OSPF to re-establish neighborships.
This issue is being tracked with Known Issue #1218538 and is expected to be resolved in the upcoming FortiOS 7.4.10, 7.6.6, and later. As part of this solution, OSPF will now check the tunnel ID presented by OSPF against the existing OSPF neighborship. If it does not match, the OSPF neighborship is cleared on the FortiGate and then reformed with the new, updated tunnel ID value.
Related articles: Technical Tip: Change in behavior of IPsec tunnel interface IP address and routing on FortiOS v7.x Technical Tip: OSPF inactivity timer expire message in the debug logs |
