SRX

Good Afternoon,

I've been having some issues with a route based VPN we have between our SRX clsuter and a customer Checkpoint 

Generally, the VPN is working fine. We have 2 subnets on our side hitting a single subnet on the customer side. 

However, since comissioning, there have been occasions when traffic suddenly stops, despite the tunnel showing as up.

After some troubleshooting and trying to catch the issue in the act, it appears to occur at the expiery of the IKE lifetime.

If I show security ike security-associations I get multiple entries from the remote address, each with a different responder cookie - IE

run show security ike security-associations    

Index   State           Initiator cookie              Responder cookie           Mode            Remote Address   
1680778 DOWN 2f3630c7793bb71d 043d90f6ba3fa714 IKEv2       xxx.yyy.107.112
1680779 DOWN 2f3630c7793bb71d 77519331f7326753 IKEv2      xxx.yyy.107.112
1680780 DOWN 2f3630c7793bb71d 693bfd25d67047c8 IKEv2       xxx.yyy.107.112

1679918 UP        2f3630c7793bb71d  ea64ec80ed888de5  IKEv2    xxx.yyy.107.112  

In the above state - no traffic will pass - although the IPSEC claims to be up...

If I manually clear the Index that is DOWN - the service will restored.

If I leave the firewall alone, eventually it seems to sort itself out and restore traffic

However a several minute outage every 8 hours is growing tiresome

Has anyone ever come accross something like this before or have any suggested solutions?

Much appreciated

Could you please insert your ipsec + ike configuration for this peer? Easier to see if anything points out.

Checkpoint is usually "policy based" where they expect some specific subnets (called encryption domain). If your SRX the renegotiates a default route-based things tends to break 🙂

You should enable debug logging on the peer: https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/request-security-ike-debug-enable.html

That should hopefully also give an indication on why the tunnel goes down. Please include this together with configuration snippets.

Hi Jonas,

Thanks very much for your input.

See ike and ipsec configuration below.

==================================================================================================

set security ike proposal CUSTOMER_IKE_PROP description CUSTOMER_IKE_PROP
set security ike proposal CUSTOMER_IKE_PROP authentication-method pre-shared-keys
set security ike proposal CUSTOMER_IKE_PROP dh-group group5
set security ike proposal CUSTOMER_IKE_PROP authentication-algorithm sha-256
set security ike proposal CUSTOMER_IKE_PROP encryption-algorithm aes-256-cbc
set security ike proposal CUSTOMER_IKE_PROP lifetime-seconds 86000

set security ike policy ike_pol_CUSTOMER_VPN mode main
set security ike policy ike_pol_CUSTOMER_VPN proposals CUSTOMER_IKE_PROP
set security ike policy ike_pol_CUSTOMER_VPN pre-shared-key ascii-text ##secretkey##

set security ike gateway gw_CUSTOMER_VPN ike-policy ike_pol_CUSTOMER_VPN
set security ike gateway gw_CUSTOMER_VPN address XXX.YYY.107.112
set security ike gateway gw_CUSTOMER_VPN external-interface reth1.0
set security ike gateway gw_CUSTOMER_VPN version v2-only

set security ipsec proposal CUSTOMER_IPSEC_PROP description REALISE_IPSEC_PROP
set security ipsec proposal CUSTOMER_IPSEC_PROP protocol esp
set security ipsec proposal CUSTOMER_IPSEC_PROP authentication-algorithm hmac-sha-256-128
set security ipsec proposal CUSTOMER_IPSEC_PROP encryption-algorithm aes-256-cbc
set security ipsec proposal CUSTOMER_IPSEC_PROP lifetime-seconds 3600

set security ipsec policy ipsec_pol_CUSTOMER_VPN perfect-forward-secrecy keys group5
set security ipsec policy ipsec_pol_CUSTOMER_VPN proposals CUSTOMER_IPSEC_PROP

set security ipsec vpn CUSTOMER_VPN bind-interface st0.xxx
set security ipsec vpn CUSTOMER_VPN ike gateway gw_CUSTOMER_VPN
set security ipsec vpn CUSTOMER_VPN ike ipsec-policy ipsec_pol_CUSTOMER_VPN
set security ipsec vpn CUSTOMER_VPN establish-tunnels immediately

==================================================================================================

The logs do seem to point towards what's happening;

The following entry recurs continuously in the log for around 10 minutes

==================================================================================================

[Aug 3 08:26:42][xxx.xxx.173.2 <-> xxx.xxx.107.112] Triggering negotiation for CUSTOMER_VPN config block
[Aug 3 08:26:42][xxx.xxx.173.2 <-> xxx.xxx.107.112] Ignoring the trigger message as there are 4 active SAs already present in the CUSTOMER_VPN config block
[Aug 3 08:26:42][xxx.xxx.173.2 <-> xxx.xxx.107.112] Triggering negotiation for CUSTOMER_VPN config block
[Aug 3 08:26:42][xxx.xxx.173.2 <-> xxx.xxx.107.112] Ignoring the trigger message as there are 4 active SAs already present in the CUSTOMER_VPN config block
[Aug 3 08:26:46][xxx.xxx.173.2 <-> xxx.xxx.107.112] Triggering negotiation for CUSTOMER_VPN config block
[Aug 3 08:26:46][xxx.xxx.173.2 <-> xxx.xxx.107.112] Ignoring the trigger message as there are 4 active SAs already present in the CUSTOMER_VPN config block
[Aug 3 08:26:46][xxx.xxx.173.2 <-> xxx.xxx.107.112] Triggering negotiation for CUSTOMER_VPN config block

etc

etc

etc

==================================================================================================

Then the following entries occur

==================================================================================================

[Aug 3 08:37:06][xxx.xxx.173.2 <-> xxx.xxx.107.112] Ignoring the trigger message as there are 4 active SAs already present in the CUSTOMER_VPN config block
[Aug 3 08:37:07][xxx.xxx.173.2 <-> xxx.xxx.107.112] Soft life timer expired for inbound CUSTOMER_VPN with spi 0x81f94a91
[Aug 3 08:37:07][xxx.xxx.173.2 <-> xxx.xxx.107.112] Triggering negotiation for CUSTOMER_VPN config block
[Aug 3 08:37:07][xxx.xxx.173.2 <-> xxx.xxx.107.112] iked_pm_trigger_callback: lookup peer entry for gateway gw_CUSTOMER_VPN, local_port=500, remote_port=500
[Aug 3 08:37:07][xxx.xxx.173.2 <-> xxx.xxx.107.112] iked_pm_trigger_callback: FOUND peer entry for gateway gw_CUSTOMER_VPN
[Aug 3 08:37:07][xxx.xxx.173.2 <-> xxx.xxx.107.112] Using existing ike SA 1682582 for gateway gw_CUSTOMER_VPN
[Aug 3 08:37:07][xxx.xxx.173.2 <-> xxx.xxx.107.112] iked_pm_trigger_negotiation Set p2_ed in sa_cfg=CUSTOMER_VPN
[Aug 3 08:37:07][xxx.xxx.173.2 <-> xxx.xxx.107.112] IPSec rekey initiated for sa_cfg CUSTOMER_VPN with inbound spi 0x1a7f31c7

==================================================================================================

Thanks again,

Scott

The configuration and logs would recommend you to configure traffic selectors on the VPN to match the Check Point configuration. The clear the tunnel and see if this stabilizes the tunnel SA's.

Information about traffic selector configuration can be found here:

https://www.juniper.net/documentation/en_US/junos/topics/example/ipsec-vpn-traffic-selector-configuring.html

A note regarding Check Points way of handling subnets.. if two /24's can be combined to a /23 (eg. 192.168.0.0/24 and 192.168.1.0/24 -> 192.168.0.0/23) it will do this. So if your two local subnets are contiguous, you should create the traffic selector with the supernet.

Let us know if this solves your issue.

Hi Jonus,

That got me close enough to the issue;

I have polices from LAN to WAN and a DMZ to WAN that use the tunnel.

I had taken addresses from a /24 subnet and used a /28 source nat pool to allow home VPN users on a separate network to access the customer subnets.

I made the mistake of putting the /28 network in the policy. Once I corrected this to the /24 the tunnels look to be negotiating fine now.

Strange how it would eventually start working with the incorrect config...

Thanks for your assistance, much apprecaited,

Scott