SRX Services Gateway
Highlighted
SRX Services Gateway

SRX 1400 inactive-tunnels

‎10-23-2017 02:16 PM

I'm seeing some odd behaviour with an SRX 1400 (12.3X48-D55.4) and the "show security ipsec inactive-tunnels" command. The firewall reports dozens of VPN tunnels as inactive, "Dynamic tunnel configuration is ready. Waiting for peer(s) to initiate negotation (1 times)" as the reason. However, I know for sure that many of these tunnels are actually up and working just fine. Clearing the tunnel and letting the firewalls renegotiate it doesn't affect anything.

 

Seems like the problem is only relared to aggressive mode / responder role tunnels, main mode tunnels are showing up correctly only if they do have an actual problem. Any idea what could cause that? Google is not really being helpful here..

5 REPLIES 5
Highlighted
SRX Services Gateway

Re: SRX 1400 inactive-tunnels

‎10-25-2017 11:40 PM

Do the active and the inactive tunnels have the same tunnel index? 

 

Anand

Highlighted
SRX Services Gateway

Re: SRX 1400 inactive-tunnels

‎10-26-2017 02:25 AM

Mh, not sure. Here's one sanitized example:

 

username@fwname_node0> show security ipsec inactive-tunnels detail
node0:
--------------------------------------------------------------------------
Location: FPC 0, PIC 0, KMD-Instance 1
ID: 131180 Virtual-system: root, VPN Name: 153001-TunnelNameCensored
Local Gateway: 123.123.123.123
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Version: IKEv1
DF-bit: clear, Bind-interface: st0.119
Port: 500, Nego#: 0, Fail#: 0, Def-Del#: 0 Flag: 0x604a29
Tunnel events:
Thu Oct 26 2017 12:19:36 +0300: Dynamic tunnel configuration is ready. Waiting for peer(s) to initiate negotation (1 times)
Fri Oct 13 2017 23:20:48 +0300: External interface's address received. Information updated (1 times)
Fri Oct 13 2017 23:20:48 +0300: Bind-interface's zone received. Information updated (1 times)
Fri Oct 13 2017 23:20:48 +0300: External interface's zone received. Information updated (1 times)
Location: FPC 0, PIC 0, KMD-Instance 1


username@fwname_node0> show security ipsec security-associations vpn-name 153001-TunnelNameCensored
node0:
--------------------------------------------------------------------------
Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<69470457 ESP:aes-cbc-128/sha1 42d3e51a 1232/ unlim - root 64916 22.222.22.222
>69470457 ESP:aes-cbc-128/sha1 e9baa29d 1232/ unlim - root 64916 22.222.22.222

{primary:node0}
username@fwname_node0> show security ipsec security-associations vpn-name 153001-TunnelNameCensored detail
node0:
--------------------------------------------------------------------------

ID: 69470457 Virtual-system: root, VPN Name: 153001-TunnelNameCensored
Local Gateway: 123.123.123.123, Remote Gateway: 22.222.22.222
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Version: IKEv1
DF-bit: clear, Bind-interface: st0.119
Port: 64916, Nego#: 364, Fail#: 0, Def-Del#: 0 Flag: 0x608a29
Tunnel events:
Thu Oct 26 2017 11:40:50 +0300: IPSec SA negotiation successfully completed (108 times)
Thu Oct 26 2017 10:01:28 +0300: IKE SA negotiation successfully completed (37 times)
Fri Oct 13 2017 23:22:11 +0300: IPSec SA delete payload received from peer, corresponding IPSec SAs cleared (1 times)
Fri Oct 13 2017 23:22:11 +0300: Tunnel is ready. Waiting for trigger event or peer to trigger negotiation (2 times)
Location: FPC 1, PIC 0, KMD-Instance 2
Direction: inbound, SPI: 42d3e51a, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 1221 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 660 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Location: FPC 1, PIC 0, KMD-Instance 2
Direction: outbound, SPI: e9baa29d, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 1221 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 660 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
Anti-replay service: counter-based enabled, Replay window size: 64

{primary:node0}

Highlighted
SRX Services Gateway

Re: SRX 1400 inactive-tunnels

‎10-26-2017 02:27 AM

And ipsec part of this particular tunnel configuration is very simple, SRX device at both ends so no proxy-id:

 

username@fwname_node0> show configuration security ipsec vpn 153001-TunnelNameCensored
bind-interface st0.119;
ike {
gateway 153001-TunnelNameCensored;
ipsec-policy g2-esp-aes128-sha;
}
establish-tunnels immediately;

Highlighted
SRX Services Gateway

Re: SRX 1400 inactive-tunnels

‎10-26-2017 07:19 PM

Hi,

 

The message "Tunnel is ready. Waiting for trigger event or peer to trigger negotiation" is an information that the device is ready to negotiate ike but there has been no event triggering it. Either this SRX is  not configured to initiate  the VPN or it is not receiving IKE packets from the other end.

From what I see from the logs the VPN seems to be working fine.
Hence, I suppose the VPN is set with APIPA IP address?
Is this seen on both ends of the tunnel or the end which has the static ip?

Shailesh
[KUDOS PLEASE! If you think I earned it!
If this solution worked for you please flag my post as an "Accepted Solution" so others can benefit..]
Highlighted
SRX Services Gateway

Re: SRX 1400 inactive-tunnels

‎10-26-2017 11:58 PM

They are aggressive mode VPNs with dynamic public IP at the other end. IKE configuration looks like this:

 

username@fwname_node0> show configuration security ike gateway 153001-TunnelNameCensored
ike-policy 153001-TunnelNameCensored;
dynamic hostname something.something.local;
external-interface reth0.0;

{primary:node0}


username@fwname_node0> show configuration security ike policy 153001-TunnelNameCensored
mode aggressive;
proposals pre-g2-aes128-sha;
pre-shared-key ascii-text "$something"; ## SECRET-DATA

 

The message itself is pretty self-explanatory, but the reason for it is not. The tunnel is up and the configuration is very simple. Maybe the lack of DPD and monitoring? Although we do have a lot of tunnels with both disabled that are not showing up on the same list.

 

To clarify, it's not about one tunnel but some 20 out of 120 tunnels on the same firewall. The other end of this example tunnel feels just fine and shows zero inactive tunnels and one active. Doesn't also seem to be every aggressive mode tunnel, just some.

Feedback