No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

IPSEC issue when establish tunnel between HW USG and Juniper SRX

Publication Date:  2016-08-31 Views:  107 Downloads:  0
Issue Description

Customer has one VPN switched to IKEv2. And it is unfortunately beeing disconected in hourly manner, sometime it survie longer (2-3 hours). If I monitor SA on USG, from time to time he can find two traffic selectors active in SA. One is regular subnet as expected, but another one is mostly Host to Host with specific ports (for example: Local: 10.10.0.10:445 Remote: 10.20.0.2:63499). He has researched that allowing subset of defined traffic selector may be the ability of IKEv2 itself . But if one site of VPN (if Juniper or Huawei cause it) try to rekey in this situation, other one (again, don't know which one, or both) reset the connection with the same error as before. So which means the issue mostly occurred during rekey process.

Alarm Information

*0.414482840 USG6600 IKEV2/7/DEBUG:[ERR]:0:? - ?:0:sadb_delete: error at the kernel on DELETE, 3

*0.414482840 USG6600 IKEV2/7/DEBUG:[MESSAGE]:done.

*0.414483700 USG6600 IKEV2/7/DEBUG:[MESSAGE]:

 IPSec_Choose_Thread: HASH value is 8 Addr num is 1389372998 uiLocal is 1348430259 uiRemote is 1389372998

*0.414483700 USG6600 IKEV2/7/DEBUG:[EXCHANGE]:ike event: read pfkey

*0.414483700 USG6600 IKEV2/7/DEBUG:[EXCHANGE]:pf_key packet processing

*0.414483700 USG6600 IKEV2/7/DEBUG:[EXCHANGE]:receive sadb expire

*0.414483710 USG6600 IKEV2/7/DEBUG:[EXCHANGE]:receive sadb expire message

*0.414483710 USG6600 IKEV2/7/DEBUG:[MESSAGE]:expire message was for outbound ipsec_sa of child_sa 52bc05e5c0

*0.414483710 USG6600 IKEV2/7/DEBUG:[MESSAGE]:ikev2_expire_sa(52bc05e5c0)

*0.414483710 USG6600 IKEV2/7/DEBUG:[MESSAGE]:expire child 52bc05e5c0 (state MATURE)

*0.414483710 USG6600 IKEV2/7/DEBUG:[MESSAGE]:ikev2_child_delete(52bc05e5c0)

*0.414483710 USG6600 IKEV2/7/DEBUG:[MESSAGE]:ikev2_child_send_delete(52bc05e5c0)

*0.414483710 USG6600 IKEV2/7/DEBUG:[MESSAGE]:already sent

*0.414483710 USG6600 IKEV2/7/DEBUG:[MESSAGE]:SADB_DELETE ul_proto=0 src=xx.xx.xx.xx[500] dst=xx.xx.xx.xx[500] satype=ESP spi=0x09ce1011

*0.414483710 USG6600 IKEV2/7/DEBUG:[MESSAGE]:sadb_delete: sa_src=xx.xx.xx.xx[500], sa_dst=xx.xx.xx.xx[500], satype=96 (ESP), spi=0x09ce1011

*0.414483710 USG6600 IKEV2/7/DEBUG:[EXCHANGE]:pf_key packet processing

*0.414483710 USG6600 IKEV2/7/DEBUG:[ERR]:0:? - ?:0:sadb_delete: error at the kernel on DELETE, 3

Handling Process


When USG establish IPSEC tunnel with packets trigger, there will be two flows exist ,while one is the host to host and the other is defined by security rule. 

HRP_A<USG6600>dis ipsec sa re xx.xxx.xx.xx
===============================
Interface: GigabitEthernet1/0/0
    path MTU: 1500
===============================
  -----------------------------
  IPsec policy name: "ipsecxxxxx"
  sequence number: 1
  mode: isakmp
  vpn: public
  -----------------------------
    connection id: 800xxx
    rule number: 5
    encapsulation mode: tunnel
    holding time: 0d 0h 5m 12s
    tunnel local : xx.xx.xxx.xxx    tunnel remote: xx.xxx.xx.xx
    flow      source: 192.168.1.1-192.168.2.1 443-443 6
                         0.0.0.0-255.255.255.255 0-65535 0
    flow destination: 10.1.1.1-10.2.1.1 50935-50935 6
                       10.3.1.0-10.3.1.255 0-65535 0

According to RFC4306, the trigger packets flow should be included in the ipsec tunnel.  Sometimes,  the negotiated flow doesn’t contain the trigger packets, there must have two flows. Like below,

 

Here is the introduction of RFC:

And we have tested in our lab and try to reproduce the issue, here is our test result.


1.      USG started negotiation automatically (auto-neg), and USG started re-negotiation, OK.

2.      USG started negotiation automatically (auto-neg), and SRX started re-negotiation, OK.

3.      USG started negotiation by packets trigger(packet), and USG started re-negotiation, OK.

4.      USG started negotiation by packets trigger(packet), and SRX started re-negotiation, NOK.

5.      SRX started negotiation, SRX started re-negotiation, OK.

6.      SRX started negotiation, USG started re-negotiation, OK.


As we tested only scenario 4 have problem, the reason is that when SRX started re-negotiation, it doesn’t have two flows but USG has two flows USG consider the TS is different between each other, which cause re-negotiation failed. 

1.     

Solution

      Since the reason is that when when packets triggered ipsec tunnel from USG side, there will have two flows while on juniper only one flow. There will have problem when rekey from Juniper side since it only has one flow then USG compare the negotiation flows it will consider abnorna, then caused the 1s interruption. To solve the issue is to let USG always start rekey but not Juniper SRX, then whether there are two flows or one flow on USG, there will always no problem. Means the solution is tomodify the sa duration to let the time on USG shorter than sa duration time on SRX, therefore, all re-negotiation will be done by USG. 

END