VPN Fortigate to ASA-5520 only up if FG300A is initiator

[#1]

I have an IPSEC VPN tunel between a FG300A and a Cisco ASA-5520. It only stays up if the FG300A is the initiator. If the ASA-5520 is the initiator, it comes up for a few seconds and then renegotiates Phase 2 (interrupting the tunnel) over and over again. If I Shut Down the VPN interface, it comes up with the FG300A as the initiator until the Phase 2 time out period elapses at which point the Cisco becomes the initiator and the problem recurs (with occasional errors logged re: Invalid SPI). The tunnel uses Interface mode and NAT' s in both directions due to overlapping networks at each end. I had to upgrade to v3.00 MR5 Patch7 and disable DPD on the FG300A just to get this far. Any ideas????

[#2]

To clarify: the tunnel only comes up if I Bring Down the VPN INTERFACE and then Bring Up System->Network->Interface->Port1. It does not work if I Bring Down the tunnel and then Bring Up under VPN->IPSEC->Monitor because the remote peer becomes the Initiator. How do I force the FG300A to ALWAYS be the initiator or ignore initiation from the remote peer?

[rwpatterson]

In the phase2 setup for the tunnel (from the CLI), enter

set auto-negotiate enable

Also check the phase2 selectors on both sides. The FGT may be a subset of the Cisco, which is why it works in one direction. The Cisco cannot open the connection because part of it' s phase2 range lies outside what the FGT will allow.... Just a thought. Good luck

[emnoc]

On the latter question, you can specify on the ASA that it only answer, or originate or is bidirectional for establishments of connections Have the ASA guys go into the ASA and edit your " crypto map statement" e.g here' s the options and example on how to set the ASA to answer only configure mode commands/options: answer-only Answer only bidirectional Bidirectional originate-only Originate only crypto map HQ_to_800A01 110 set connection-type answer-only Hope this helps.

[#5]

Excellent suggestions --- thank you both! I' m still confused as to the root cause...If phases 1 and 2 pass when the FGT initiates the tunnel, doesn' t that mean that the relevant SA properties match and should therefore do so when the other side initiates it? I' ve confirmed thst the phase 2 ranges are identical. So...I' m thinking the root cause is a bug or incompatibility related to how the FGT implements/parses/compares address groups for SA during phase 2 negotiation. ANYWAY, I think preventing the ASA from iniating the tunnel will get around the problem (assuming the setting applies to re-negotiation of phase 2 as well), but I' m going to start with setting auto-negotiate to enable on the FGT to learn more about the behavior. It seems like enabling auto-negotitate will improve the likelihood that the FGT re-negotiates first but not guarantee it. The phase 2 keylife on both sides is 28800 sec (8 hr) and renegotiation occurred after 6 hrs (I assume that is by design --- like DHCP renewal). If both sides use the same timing (75% keylife) there' s no guarantee the FGT will auto-negotiate before the ASA does (due to generated traffic). For all I know, the IPSEC standard itself may determine that roles are reversed (Responder vs Initiator) for renegotiation.

[emnoc]

I think with SA rengoiation timers either side can re-negotiate. the lessor of the time value is typically used in IKE ph1 negotiation and I think the same still holds true with the ph2 SA. It' s still unclear to me as to what your trying to accomplish? If the ph2 SA timers count down, it will only recycle with a new SA as long as IKE ph1 is still establish. Since SAs are uni-directional, and rely on a valid phase1 establishment, and upon termination of your phase1 SA, then any phase2 SA should magically be terminate as well.

[#7]

I' ve always set Phase 2 < Phase 1 timer (otherwise there is no point in having an Phase 2 timer). In any case, I' ll try setting Phase 1 < Phase 2 and see if that works around the problem. NOTE: set auto-negotiate enable did not resolve it. Log Messages (xxx.xxx.xxx.xxx is FGT peer IP) are below. You can see where they show " Initiator" for Main Main messages when the tunnel comes up inittaly, and " Responder" when renegotiating. INITIAL TUNNEL Responder: tunnel yyy.yyy.yyy.yyy, transform=ESP_3DES, HMAC_SHA1 Responder: parsed yyy.yyy.yyy.yyy quick mode message #2 (DONE) Responder: tunnel xxx.xxx.xxx.xxx/yyy.yyy.yyy.yyy install ipsec sa Responder: sent yyy.yyy.yyy.yyy quick mode message #1 (OK) Initiator: tunnel yyy.yyy.yyy.yyy, transform=ESP_3DES, HMAC_SHA1 Initiator: sent yyy.yyy.yyy.yyy quick mode message #2 (DONE) Initiator: tunnel xxx.xxx.xxx.xxx/yyy.yyy.yyy.yyy install ipsec sa Responder: sent yyy.yyy.yyy.yyy quick mode message #1 (OK) Initiator: sent yyy.yyy.yyy.yyy quick mode message #1 (OK) Initiator: parsed yyy.yyy.yyy.yyy main mode message #3 (DONE) Initiator: sent yyy.yyy.yyy.yyy main mode message #3 (OK) Initiator: sent yyy.yyy.yyy.yyy main mode message #2 (OK) Initiator: sent yyy.yyy.yyy.yyy main mode message #1 (OK) PHASE 2 RENEGOTIATION (repeats indefinitely) Received ESP packet with unknown SPI. Deleted an IPsec SA on the tunnel to yyy.yyy.yyy.yyy:500 Responder: tunnel yyy.yyy.yyy.yyy, transform=ESP_3DES, HMAC_SHA1 Responder: parsed yyy.yyy.yyy.yyy quick mode message #2 (DONE) Responder: tunnel xxx.xxx.xxx.xxx/yyy.yyy.yyy.yyy install ipsec sa Responder: sent yyy.yyy.yyy.yyy quick mode message #1 (OK) Responder: tunnel yyy.yyy.yyy.yyy, transform=ESP_3DES, HMAC_SHA1 Responder: parsed yyy.yyy.yyy.yyy quick mode message #2 (DONE) Responder: tunnel xxx.xxx.xxx.xxx/yyy.yyy.yyy.yyy install ipsec sa Responder: sent yyy.yyy.yyy.yyy quick mode message #1 (OK) Responder: sent yyy.yyy.yyy.yyy main mode message #3 (DONE) Responder: sent yyy.yyy.yyy.yyy main mode message #2 (OK) Responder: sent yyy.yyy.yyy.yyy main mode message #1 (OK) Deleted an Isakmp SA on the tunnel to yyy.yyy.yyy.yyy:500

[#8]

This workaround seems to have worked! I changed Phase 1 to Agressive Mode with key life 120 seconds and monitored connectivity and tunnel negotiations for 30 minutes or so before changing the key life to 14400 (permanently). I still don' t understand why Phase 2 renegotiation never succeeeded but hours of testing everthing I can think of has made me less curious than usual... Anyway, thanks for all of the help!!

[severach]

ORIGINAL: johns99 If the ASA-5520 is the initiator, it comes up for a few seconds and then renegotiates Phase 2 (interrupting the tunnel) over and over again.

The two sides may not be equal. Sometimes the responder adjusts the parameters to what the initiator has requested so the tunnel will come up. By comparing the responder debug log on each side you should be able to see what the differences are.

If phases 1 and 2 pass when the FGT initiates the tunnel, doesn' t that mean that the relevant SA properties match and should therefore do so when the other side initiates it?

Between two Fortigate yes. With other routers no. FortiOS defaults and techniques prefer a hard set phase 2 quick mode selector. Many other router brands don' t work this way. They are set up to use 0.0.0.0 as the quick mode selector with the equivalent of “set selector-match subset” enabled. They will provide whatever quick mode selector your Fortigate wants but will typically accept anything as a quick mode selector. The firewall controls what traffic can pass.

So...I' m thinking the root cause is a bug or incompatibility related to how the FGT implements/parses/compares address groups for SA during phase 2 negotiation.

If the Fortigate is refusing the connection then it will be detailed in the debug log. For some problems I' ve had to analyze days of debug logs to figure out the pattern.

ANYWAY, I think preventing the ASA from iniating the tunnel will get around the problem (assuming the setting applies to re-negotiation of phase 2 as well), but I' m going to start with setting auto-negotiate to enable on the FGT to learn more about the behavior.

This shouldn' t work. Typically routers create a new SA rather than reusing an existing SA unless it matches exactly. Even if you force the tunnel up on the Fortigate the Cisco will probably want to create another when it wants to send something. I would expect a lot of connectivity problems.

The phase 2 keylife on both sides is 28800 sec (8 hr) and renegotiation occurred after 6 hrs (I assume that is by design --- like DHCP renewal).

My Fortigate with FortiOS 3.0 to a Checkpoint renegotiates anywhere from 50-0 seconds from the end of the tunnel. Renegotiating seamlessly lets the existing tunnel expire and creates a new one. The Cisco may decide to create another tunnel because the one you forced up wasn' t a match.

ORIGINAL: emnoc … upon termination of your phase1 SA, then any phase2 SA should magically be terminate as well.

The IPSec standard and FortiOS KB specifically state that phase 2 may continue after their phase 1 goes down. The phase 2 tunnels will stay up but any communication about them will require a new phase 1. However many routers do drop their phase 2 when the phase 1 goes down. Fortigate phase 2 will continue after the phase 1 expires unless the other router brings them down.