Troubleshooting Tip: SD-WAN Integration Problem in IPSec Tunnel

[yzayani]

Description	This article describes how to troubleshoot the multipoint dial-up IPsec VPN deployment issue, where FortiGate could send return traffic through the wrong tunnel instance, which might lead to asymmetric routing and dropped connections.
Scope	SD-WAN or ADVPN hub-spoke deployment.
Solution	Root Cause: FortiGate handles all dial-up tunnels on the same port as a logical port. It is unable to bind the response traffic to a particular tunnel instance. Even with proper routing, the response traffic can be sent out through any tunnel under that port. In an ADVPN hub and spoke architecture, both Spoke_1 and Spoke_2 advertise the identical subnet to the hub via BGP. When Spoke_1 initiates traffic toward the subnet located behind the hub, the hub erroneously updates the gateway IP in its session table, causing the return traffic to be forwarded to Spoke_2. Routing Table: get router info routing-table details 172.18.55.195/3 Routing entry for 172.18.55.195/32 Known via "bgp", distance 20, metric 0, best * 10.255.107.19, tag 107 (recursive is directly connected, VPN1) * 10.255.107.21, tag 107 (recursive is directly connected, VPN1) Both recursive next hops are resolved to VPN1, but FortiGate does not recognize the difference between tunnel instances (VPN1_1 / VPN1_2). Debug Flow: id=20085 traceid=101 func=ipsecdevhardstartxmit line=642 msg="IPsec tunnel lookup: VPN1_1" The return traffic is sent via VPN1_1, even though the original session was received via VPN1_2. Recommended changes: Configure point-to-point tunnels. Configure SD-WAN members with individual ports per tunnel. If exchange-ip-addr4 is present in the configuration: show vpn ipsec phase1-interface Tunnel-name config vpn ipsec phase1-interface     edit "Tunnel-name"         set type dynamic         set interface "interface-name"         set ike-version 2         set peertype any         set net-device disable         set exchange-ip-addr4 100.91.3.14         set proposal aes256gcm-prfsha256         set add-route disable         set localid "local-id"         set localid-type fqdn         set dpd on-idle         set dhgrp 31         set network-overlay enable         set network-id 35         set exchange-fgt-device-id enable         set transport udp-fallback-tcp         set psksecret ENC          set dpd-retrycount 2         set dpd-retryinterval 5     next end So the 100.91.3.14 should be configured in the right VDOM. After that, flush IKE (diagnose vpn ike gateway flush name) on the Hub and Spoke. Related articles: Troubleshooting Tip: Packet distribution for aggregate dial-up IPsec tunnels using location ID  Troubleshooting Tip: Embedded SD-WAN SLA information in ICMP probes