How to fix connectivity issue between Dialup hub FortiGate and multiple Dial-in client FortiGates

This article describes troubleshooting tips for some scenarios with FortiGate acting as Dialup IPSec Hub and multiple Dial-in Client FortiGates.

Scope

FortiGate.

Solution

Scenario 1

Losing connectivity from Hub FortiGate overlay IP towards Spoke tunnel overlay IP, only when multiple dial-in client connects to the same Dial-up hub. If checking the flow trace on the hub, it is possible to see that the packet is entering in parent tunnel, but later it is not going out via the actual dialup tunnel.

HUB # id=65308 trace_id=6 func=print_pkt_detail line=5894 msg="vd-root:0 received a packet(proto=1, 10.254.101.1:10->10.254.101.200:2048) tun_id=0.0.0.0 from local. type=8, code=0, id=10, seq=0."
id=65308 trace_id=6 func=init_ip_session_common line=6080 msg="allocate a new session-0000443b, tun_id=0.0.0.0"
id=65308 trace_id=6 func=ip_session_confirm_final line=3113 msg="npu_state=0x0, hook=4"
id=65308 trace_id=6 func=ipsecdev_hard_start_xmit line=662 msg="enter IPSec interface SPEC-1, tun_id=0.0.0.0"

Also, if checking the gateway list, it shows incorrect virtual-interface-addr (hub tunnel interface IP is 10.254.101.1 and remote FortiGate tunnel interface ip is 10.254.101.200):

vd: root/0
name: SPEC-1_0
version: 2
interface: port1 3
addr: 10.9.10.116:500 -> 10.9.10.239:500
tun_id: 10.9.10.239/::10.0.0.159
remote_location: 0.0.0.0
network-id: 101
virtual-interface-addr: 10.254.101.1 -> 10.254.101.254 <--------
created: 20s ago
peer-id: 10.9.10.239
peer-id-auth: no

In the above output, it shows virtual-interface-addr as 10.254.101.1 -> 10.254.101.254 instead of 10.254.101.1 -> 10.254.101.200.

Solution

When traffic is initiated from the hub side, the route should have more specific information to know which tunnel is the destination. Therefore it needs a mechanism to fetch overlay IP and this can be achieved by enabling exchange-interface-ip.

FortiGate A:

FGT_1 (root) # config vpn ipsec phase1-interface
FGT_1 (phase1-interface) # edit SiteA-to-SiteB
FGT_1 (SiteA-to-SiteB) # set exchange-interface-ip enable
FGT_1 (SiteA-to-SiteB) # end

FortiGate B:

FGT2 # config vpn ipsec phase1-interface
FGT2 (phase1-interface) # edit SiteB-to-SiteA
FGT2 (SiteB-to-SiteA) # set exchange-interface-ip enable
FGT2 (SiteB-to-SiteA) # end

Now, if checking the gateway list, it will show the correct virtual interface address and connectivity should restore from the hub to dial-in client FortiGate.

vd: root/0
name: SPEC-1_0
version: 2
interface: port1 3
addr: 10.9.10.116:500 -> 10.9.10.239:500
tun_id: 10.9.10.239/::10.0.0.159
remote_location: 0.0.0.0
network-id: 101
virtual-interface-addr: 10.254.101.1 -> 10.254.101.200
created: 10s ago
peer-id: 10.9.10.239
peer-id-auth: no

Scenario 2

Dialup tunnels are flapping continuously when there are multiple Dail-in Client FortiGates terminating on the same hub with an add-route option enabled.

Solution

FortiOS uses an add-route to announce the network has been encrypted by a spoke or dialup client to the HUB and eventually adds this route to the FortiGate FIB, this takes place during the dynamic tunnel negotiation.

If there is a network setup or design where the same subnet can be reached through two different phase1s, like the dual link or ECMP to the same network, this can be an issue in a dial-up VPN environment unless there is the right setting under VPN.

It is possible to enable route-overlap option so that the same subnet can be learned and installed in FIB by IKE through different phase1s.

config vpn ipsec phase2-interface
edit name
set route-overlap allow
end

Another option is to disable add-route under phase1 settings and use dynamic routing.