1 IPsec tunnel why apparent multiple Security Associations

[slouw]

I have a single IPsec tunnel with Phase 1 and Phase 2 up.

It is not passing traffic so something is wrong.

When I do a get vpn ipsec tunnel name XXXX command I am used to seeing one SA in the output.

Now I have 4 see below.

It might be on account of issuing diagnose vpn ike restart a couple of times.

What are these extra associations?

thanks.....

 

[kaman]

Hi slouw,

Once the tunnel is up, traffic will be encapsulated in ESP (Encapsulating Security Payload) protocol and sent to the remote peer.

Checklist:

1) Make sure the quick mode selector defined in Phase2 is configured properly to allow the traffic flow, which is having the issue.

2) Check the IPv4 policies and confirm:

a) If there is policy defined for this traffic flow.
b) If there are any source and destination addresses defined, make sure it is configured to allow this traffic flow.

3) If the issue still persists:

a) Enable packet capture for remote peer’s ip address and set protocol to 50(ESP).

b) Open two SSH session and run the below commands:

SSH session 1:
# diagnose debug console timestamp enable
# diagnose debug flow filter addr <destination-IP>
# diagnose debug flow filter proto <1 or 17 or 6> (optional) where 1=ICMP, 6 = TCP, 17 = UDP…
# diagnose debug flow show iprope enable
# diagnose debug flow trace start 1000

Please refer to the below documents for more information:

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Troubleshooting-IPsec-Site-to-Site-T...

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-IPsec-VPN-is-up-but-network-is-not-r...

I hope it will help you.

[slouw]

The tunnel has started working for reasons unknown.

Probably something I was not understanding.

I would appreciate it if anyone would comment on the multiple SAs visible.

Is this normal?

I check again now a day later the extra SAs are gone.

Am I correct in saying I should expect to see one SA per IPSec tunnel?

Much appreciate any comments...

[Toshi_Esumi · Accepted solution]

You needed to check the status/progress on the other end when it was not working. Or should have run IKE debugging one of KBs @kaman  provided the link on the local FGT to see what kind of exchanges were happening.

Most likely scenario was the local end was successfully completing the negotiation and sent out IKE_AUTH_Response (IKEv2's last message if a single network selector set), but somehow the other end either didn't receive the message or rejected it, then requested a new set of SAs to be established.
I would guess those half/almost-established SA pairs would be there until timeout.

Toshi

[srajeswaran]

Ideally the number of phase2 SAs depends on the number of traffic selector pairs you define , in your case you have defined 0.0.0.0/0 as src and dst, which means we expect only 1 SA. So the additional SA could be a timing issue with negotiation.

I have seen multiple SA concepts with other vendors like juniper - Multiple SAs negotiates with the same traffic selector on the same IKE SA. By negotiating multiple SAs, the peer gateways have more replay windows. If the peer gateways create separate multiple SAs for the configured Forwarding-Classes (FC), then potentially a separate anti-replay window is available for each FC value. 
ref: https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/ref/statement/multi-sa.h...

if your peer is an SRX device check if this option is enabled.

[slouw]

Thank you for replies appreciated...