Description

IPSec VPN, once configured, can be established in two ways.

  • With the 'establish-tunnels immediately' statement - the tunnel is established immediately when the configuration is committed.
  • Without 'establish-tunnels immediately' -  the tunnel will be established on-traffic.


However 'establish-tunnels immediately' may trigger an undesirable outcome, when configured on both ends of the tunnel.

Symptoms

With 'establish-tunnels immediately' statement configured on both ends of the tunnel, the tunnel will be established even without allowing IKE as host-inbound-traffic on an IKE listener interface.

Solution

The knob "host-inbound-traffic" only checks for allowing incoming IKE packets.
Without allowing IKE, the VPN comes UP as the said SRX becomes the initiator and the host-inbound-traffic (IKE) is not required.

This is expected behavior when establish-tunnels immediately is configured on both ends of the tunnel. See below:

Example topology:

SRX_A ge-0/0/0.0 --- ge-0/0/0.0 SRX_B

If establish-tunnels immediately is configured on both ends, both of the nodes will try to initiate the IKE phase 1 negotiation. This first packet is generated by the node itself and the following flow session gets created:
Session ID: 105097, Policy name: self-traffic-policy/1, Timeout: 42, Valid
In: 10.1.1.2/500 --> 10.1.1.1/500;udp, If: .local..0, Pkts: 7, Bytes: 1352
Out: 10.1.1.1/500 --> 10.1.1.2/500;udp, If: ge-0/0/0.0, Pkts: 5, Bytes: 1220

The first packet from the peer node will match this existing session; as a result, allowing phase 1 negotiation to occur.
If this behavior is considered undesirable, then remove establish-tunnels immediately from one end of the tunnel; or check that IKE is allowed correctly on either side.

Modification History

2019-06-21: updated title, and added 'cause' notes.