Skip to main content
slouw
slouw
Explorer III
November 6, 2023
Solved

1 IPsec tunnel why apparent multiple Security Associations

  • November 6, 2023
  • 4 replies
  • 4591 views

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.....

2023-11-07 08h27m46s0010 Extra SAs.jpg

 

Best answer by Toshi_Esumi

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

4 replies

kaman
Staff
kaman
Staff
November 7, 2023

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-Tunnel/ta-p/195672


https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-IPsec-VPN-is-up-but-network-is-not-reachable/ta-p/192887

 

I hope it will help you.

    slouw
    slouwAuthor
    Explorer III
    November 7, 2023

    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
    SuperUser
    Toshi_EsumiAnswer
    SuperUser
    November 7, 2023

    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
      Staff
      srajeswaran
      Staff
      November 8, 2023

      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.html

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

        slouw
        slouwAuthor
        Explorer III
        November 8, 2023

        Thank you for replies appreciated...

        Terms & ConditionsAccessibility statement