VPN - Phase 2 Issue

[B1202]

Hello,

I have multiple IPSEC site-to-sites terminating on our Fortigate. I recently setup a new site-to-site with an ASA that has multiple (15) subnets.  I created 15 different phase 2 selectors which I know also match on the ASA side.  Since the tunnel has been setup we can access the resources on the other side however, I randomly see phase 2's go down then instantly go back up.  They appear to randomly go down and then right back up.

Phase 1

edit "Phase1-Name"
set type static
set interface "port1"
set ip-version 4
set ike-version 1
set local-gw x.x.x.x
set keylife 86400
set authmethod psk
set mode main
set peertype any
set passive-mode disable
set exchange-interface-ip disable
set mode-cfg disable
set proposal aes256-sha1
set localid ''
set localid-type auto
set auto-negotiate enable
set negotiate-timeout 30
set fragmentation enable
set dpd on-demand
set forticlient-enforcement disable
set comments ''
set npu-offload enable
set dhgrp 2
set suite-b disable
set wizard-type custom
set xauthtype disable
set mesh-selector-type disable
set idle-timeout disable
set ha-sync-esp-seqno enable
set auto-discovery-sender disable
set auto-discovery-receiver disable
set auto-discovery-forwarder disable
set encapsulation none
set nattraversal disable
set rekey enable
set remote-gw x.x.x.x.
set monitor ''
set add-gw-route disable
set psksecret ENC XXXX
set dpd-retrycount 3
set dpd-retryinterval 20

Phase 2

edit "Phase2Name"
set phase1name "Phase1Name"
set proposal aes256-sha1
set pfs enable
set dhgrp 2
set replay enable
set auto-negotiate enable
set auto-discovery-sender phase1
set auto-discovery-forwarder phase1
set keylife-type seconds
set encapsulation tunnel-mode
set comments ''
set protocol 0
set src-addr-type subnet
set src-port 0
set dst-addr-type subnet
set dst-port 0
set keylifeseconds 28800
set src-subnet x.x.x.x x.x.x.x
set dst-subnet x.x.x.x x.x.x.x

These are the debugs I see when the phase2 goes down and back up.

ike 0:Phase1Name:3821: dec 40A58E4D729F089C3BE5438D59B58A9308100501C7C04B7C0000004C0C0000183EC676DDCC3C4761587654F44B4C1B444DF9B20C000000100000000103040001A5FD13550000000000000000
ike 0:Phase1Name:3821: recv IPsec SA delete, spi count 1
ike 0:Phase1Name:3821: deleting IPsec SA with SPI a5fd1355
ike 0:Phase2Name: deleted IPsec SA with SPI a5fd1355, SA count: 0
ike 0:Phase1Name: sending SNMP tunnel DOWN trap for Phase2Name
ike 0:Phase1Name:Phase2Name: IPsec SA connect 42 x.x.x.x->x.x.x.x:500
ike 0:Phase1Name:Phase2Name: using existing connection
ike 0:Phase1Name:Phase2Name: config found
ike 0:Phase1Name:Phase2Name: IPsec SA connect 42 x.x.x.x->x.x.x.x:500 negotiating
ike 0:Phase1Name:3821: cookie 40a58e4d729f089c/3be5438d59b58a93:6a2f23f8
ike 0:Phase1Name:3821:Phase2Name: initiator selectors 0 0:x.x.x.x (Our side of phase 2) 0:0->0:ASA side subnet of the phase 2

[ede_pfau]

Renegotiating phase2 - if that alone is a nuisance depends on how often it happens.

You mentioned that it appears to be random...you see that if the phase2 keepalive intervals on both sides differ. You might check the ASA side for matching parameters.

[emnoc]

Agreed, random going down is okay if they are going back up on interesting traffic. Could be the ASA is using lifetime or bytes for ph2 lifetime values. They do NOT need to match but should and should always be lower than the ph1 lifetimes.

Also I notice your set for 

set keylifeseconds 28800

CiscoASA, so they can confirm and configured globally or in the peer

crypto ipsec-security association lifetime seconds 28800

or

crypto map vpn2fgt 10 ipsec-isakmp set security-association idle-time 28800 set peeer x.x.x.x set transform blahblah match address blahblahaccesslist Anything done at the cryptomap overwrites global settings  

Ken Felix