Re: Only ASA cannot initialize VPN to Juniper.

Can you check and confirm if ike is enabled under the host inbound services for ge-0/0/14 binded security-zone.

Hope this helps.

Regards,Visitor--------------------------------------------------​--------------------------------------------------​---If this post was helpful, please mark this post as an "Accepted Solution".Kudos are always appreciated

If / when these don't match on the two ends of a VPN tunnel, there can be situations where the tunnel state is out of sync. One side might think there are established SAs for a tunnel, the other side does not. I would suggest you tune the timeouts to match on both sides and see if that helps clear up the issues you are seeing.

Re: Only ASA cannot initialize VPN to Juniper.

I think you have right, i setup lifetime like in cisco and it's much better but still no perfect. I have every 8h break 10min befor juniper again create tunnel, and always juniper is initiator.Should i tune lifetime again? it'll be different then in cisco.

Re: Only ASA cannot initialize VPN to Juniper.

1. Disable vpn-monitor on your SRX side. vpn-monitor is a Juniper proprietary protocol, the ASA is not going to understand it and is just going to drop the monitor packets.

2. Enable DPD (Dead Peer Detection) on the ASA. You have it enabled on your SRX with the default settings, which are interval 10 seconds and threshold 5. On the ASA, the defaults are 10 seconds and interval 2. You can set the interval/threshold on the ASA to match the SRX, or you can set the SRX to match the ASA defaults.

I disable monitoring and setup DPD and the break is take much more time. Any other ideas?

Sorry about that, I rushed through the documentation and wasn't clear.

On the ASA, the behavior is as such:

isakmp keepalive threshold <threshold> retry <retry-interval>

The default threshold is 10, and the default retry-interval is 2 (at least it was last time I checked.)

That means that if encrypted traffic is not seen on the tunnel for 10 seconds (the threshold), then the ASA will send a R-U-THERE packet. If it does not get a response, after 2 seconds (the retry-interval), it will send another R-U-THERE. It will do this up to 3 times, for a total of 4 R-U-THERE attempts. If, after 4 R-U-THERE attempts (the initial, plus 3 retries), it does not receive a response, it considers the peer "Dead."

The retry-count is not configurable on the ASA, it is hard set to 3, which means 4 total attempts.

To make your SRX match, set your dead-peer-detection under the ike gateway with threshold 10 and interval 2.

You can do a "show isakmp sa detail" and look at the details of the Phase 1 SA's. You should see something like this:

It's confusing that the ASA and SRX do not use the word "threshold" to mean the same thing.

In that case, it's a judgement call. You could set the SRX to 10 seconds and 3 retries, and then set the ASA retry-interval to 10 (since it's locked to a retry count of 3). That would make them match, at least. You'd have a possible 40-second max delay before peers were detected dead.

If your timers don't match, then the ASA might detect a dead peer faster than the SRX, but if the ASA says "my peer is dead, I'm going to try to re-establish" and the SRX still thinks its peer is alive during that window of 30 seconds or so where they're out of sync, I don't know if the SRX would honor the renegoiate request from the ASA or drop it. That might have to be tested in a lab to see what happens there.

Re: Only ASA cannot initialize VPN to Juniper.

I've tied turning off DPD in a aggressive mode VPN between an SRX and Sonicwall TZ100. The Sonicwalls re-establish attempts do not work unless the SRX considers the peer dead. I have since turned on "respond bad spi" and have not tested to see if that makes a difference.

On the SRX DPD settings...... i thought the interval was the period of time that could pass without seeing traffic before sending a DPD R_U_THERE (assuming "always send" is not turned on), and that the threshold was the number of failed attempts before a "dead peer" state is reached.

Re: Only ASA cannot initialize VPN to Juniper.

I've tied turning off DPD in a aggressive mode VPN between an SRX and Sonicwall TZ100. The Sonicwalls re-establish attempts do not work unless the SRX considers the peer dead. I have since turned on "respond bad spi" and have not tested to see if that makes a difference.

"respond bad spi" is dependent upon the remote side sending the "bad spi" message. Depending on what kind of device it is and how it's configured, this may or may not have a noticeable effect.

On the SRX DPD settings...... i thought the interval was the period of time that could pass without seeing traffic before sending a DPD R_U_THERE (assuming "always send" is not turned on), and that the threshold was the number of failed attempts before a "dead peer" state is reached.

The interval is how long the SRX will wait without seeing incoming traffic on the tunnel before it sends an R_U_THERE. However, again, this is different on the SRX vs. ASA. I have not found any documentation on anything resembling a "retry timer" on the SRX. The most I have found is that the ScreenOS devices, the "retry interval" is the same as the defined interval, and the threshold is the number of failed attempts before the peer is considered "dead." I'm going under the assumption that the SRX behaves the same as ScreenOS for these purposes.

Looking back at my own posts, it looks like I confused even myself.

Let's reset and start again.

ASA: threshold: 10 seconds retry-inteval: 10 seconds Since the ASA is hard-coded to a retry-count of 3, this is a total delay of 40 seconds. the initial 10 second threshold, then 3 retries with 10 second wait. After 40 seconds, the peer is "dead."

If you want to get more aggressive (and have busy tunnels, otherwise it could cause the tunnels to tear down prematurely) you could try ASA: threshold 5, retry-interval 5, and SRX interval 5, threshold 4. That would be 20 seconds on both ends. You could also use "always send" if the tunnels aren't busy.

Remember that the ASA and SRX have quite different meanings of "threshold."

Unless I've tangled myself up again trying to keep it straight in my head, these settings should at least get the timers to match on both sides.