SRX

Expand all | Collapse all

Route Based VPN - Traffic Outage for every IKE lifetime - Multiple Responder Cookies

Jump to Best Answer
  • 1.  Route Based VPN - Traffic Outage for every IKE lifetime - Multiple Responder Cookies

    Posted 08-02-2018 04:21

    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

     

     



  • 2.  RE: Route Based VPN - Traffic Outage for every IKE lifetime - Multiple Responder Cookies

     
    Posted 08-02-2018 11:11

    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.



  • 3.  RE: Route Based VPN - Traffic Outage for every IKE lifetime - Multiple Responder Cookies

    Posted 08-03-2018 01:07

    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

     

     



  • 4.  RE: Route Based VPN - Traffic Outage for every IKE lifetime - Multiple Responder Cookies
    Best Answer

     
    Posted 08-03-2018 06:19

    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.



  • 5.  RE: Route Based VPN - Traffic Outage for every IKE lifetime - Multiple Responder Cookies

    Posted 08-06-2018 01:28

    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