IPsec VPN IKEv2 negotiation issue between FTD 6.4 and FTD 7.0.1

[jumperdub]

Hi all

FTD 6.4 Local subnet: 10.1.21.0/24, 10.1.180.0/24, 192.168.1.0/24

FTD 7.0.1 Local subnet: 10.5.0.0/16

T1: On the FTD 7.0.1 as INITIATOR has made some traffic for 2 subnet and the child SA created with particular 2 subnets

T2: On the FTD 6.4 as RESONDER has make another traffic 192.168.1.0/24 which is still not created in IKEv2 yet. After traffic created. IKEv2 start new negotiated and only new Child sa active as below

It’s something like we need to create traffic from INITIATOR only so the existing Child SA will be remain

[Rob Ingram]

@jumperdub not sure I fullly understand your question.

With a policy based VPN you need to generate traffic in order for the VPN to be established, hence why you'd not see an IKEv2 or IPSec SA. If no interesting traffic is sent over the tunnel, after a while the tunnel will be closed. Only when more interesting traffic will be re-established.

[MHM Cisco World]

usually Initiator  is Site, branch and Spoke
and responder is HQ and Hub

the initiator must initiate traffic before the child crypto build in both peer.

[jumperdub]

As I have opened the TAC case, what I got from them is when the traffic is started from one direction. we see the local source and remote destination ports as UDP 4500 as expected but when started from the peer side we see this as the local source port of 4500 and a random high port as the remote destination. This is causing the sessions to fail when the new child SAs are being formed due to the port change occurring as seen.

The FTDs on both sides are behind the Huawei home router (HG8245H) which we cannot configure to disable PAT for this traffic.