SRX

Hello community, 

I am setting some policy-based IPSec from a SRX220 running [12.1X46-D65.4] I have a total of 7 Tunnels and 4 of them have Phase 1 UP, However When I checked the commando: "show security ipsec inactive-tunnels" I am seeing the following:

Total inactive tunnels: 3
Total inactive tunnels with establish immediately: 3
ID Port Nego# Fail# Flag Gateway Tunnel Down Reason
7 500 0 0 600829 111.11.11.11 SA not initiated
4 500 0 0 600829 222.22.22.22 SA not initiated
6 500 0 0 600829 333.33.33.33 SA not initiated

Any idea Why this reason is showing Up?

All Tunnels are set in the same way (7 in total) and only these 3 are not getting into an UP State even in phase 1. 

This is the config from one of the tunnels

set security ike proposal CNFL authentication-method pre-shared-keys
set security ike proposal CNFL dh-group group2
set security ike proposal CNFL authentication-algorithm sha1
set security ike proposal CNFL encryption-algorithm 3des-cbc
set security ike proposal CNFL lifetime-seconds 3600
set security ike policy CNFL mode main
set security ike policy CNFL proposals CNFL
set security ike policy CNFL pre-shared-key ascii-text "fevifevefivbivbf"
set security ike gateway CNFL ike-policy CNFL
set security ike gateway CNFL address 111.11.11.11
set security ike gateway CNFL external-interface ge-0/0/0
set security ipsec proposal CNFL protocol esp
set security ipsec proposal CNFL authentication-algorithm hmac-sha1-96
set security ipsec proposal CNFL encryption-algorithm 3des-cbc
set security ipsec proposal CNFL lifetime-seconds 3600
set security ipsec policy CNFL proposals CNFL
set security ipsec vpn CNFL ike gateway CNFL
set security ipsec vpn CNFL ike ipsec-policy CNFL
set security ipsec vpn CNFL establish-tunnels immediately
set security address-book global address CNFL 192.168.17.25/32
set security address-book global address CNFL_PRODUCCION 192.168.17.45/32
set security policies from-zone Internal to-zone Internet policy Internal-to-CNFL match source-address Network-A
set security policies from-zone Internal to-zone Internet policy Internal-to-CNFL match destination-address CNFL
set security policies from-zone Internal to-zone Internet policy Internal-to-CNFL match destination-address CNFL_PRODUCCION
set security policies from-zone Internal to-zone Internet policy Internal-to-CNFL match application any
set security policies from-zone Internal to-zone Internet policy Internal-to-CNFL then permit tunnel ipsec-vpn CNFL
set security policies from-zone Internal to-zone Internet policy Internal-to-CNFL then permit tunnel pair-policy CNFL-to-Internal
set security policies from-zone Internet to-zone Internal policy CNFL-to-Internal match source-address CNFL
set security policies from-zone Internet to-zone Internal policy CNFL-to-Internal match source-address CNFL_PRODUCCION
set security policies from-zone Internet to-zone Internal policy CNFL-to-Internal match destination-address Network-A
set security policies from-zone Internet to-zone Internal policy CNFL-to-Internal match application any
set security policies from-zone Internet to-zone Internal policy CNFL-to-Internal then permit tunnel ipsec-vpn CNFL
set security policies from-zone Internet to-zone Internal policy CNFL-to-Internal then permit tunnel pair-policy Internal-to-CNFL

Thanks for all the help

Can you confirm that the phase one is up

show security ike security-associations

And if it is up then go to the other side (responder) and look at the kmd logs.

show log kmd-logs

Hi All,

Was this issue ever resolved?

I'm currently facing this issue and the remote responder's kmd logs aren't showing a whole lot of useful info. 

Thanks

Hi, tsizzle63

I would advise to create a new post, this one is quite old.

Well without seeing the logs its hard to know where to start.  Here is the outline recommended for situations where phase 1 is up but phase 2 does not establish.

Look for the log messages listed here in the kmd file on the responder to see where the mismatch in configuration lies.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB10099

Also comparing configurations can help.  At the end of the day some parameter in the phase 2 is not  a match between the two peers.

Hi spluluka,

Apologies for wasting time, you are indeed correct about mismatching phase 2. I had misinterpreted one of the messages in the log...

Anyways the issue has been identified. 

Thanks.