|
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 dial-up tunnel.
diagnose debug flow filter daddr 10.254.101.200
diagnose debug flow filter proto 1
diagnose debug flow show function-name enable
diagnose debug enable
diagnose debug flow trace start 10
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):
HUB # diagnose vpn ike gateway list
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 the 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
If checking the gateway list, it will show the correct virtual interface address, and connectivity should be restored from the hub to the dial-in client FortiGate.
HUB # diagnose vpn ike gateway list
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: Dial-up tunnels are flapping continuously when multiple dial-in client FortiGates are 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.
Related articles:
|
