04-05-2022 12:55 AM - edited 04-05-2022 08:19 AM
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
04-05-2022 09:00 AM
@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.
04-07-2022 04:36 AM
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.
04-07-2022 11:15 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide