Site-to-Site IPSec Excessive Rekeying on Only One Tunnel on System Logs

Site-to-Site IPSec Excessive Rekeying on Only One Tunnel on System Logs

124773
Created On 09/25/18 19:50 PM - Last Modified 05/31/23 21:39 PM


Resolution


Symptom

There is site-to-site IPSec excessive rekeying on one tunnel on system logs, while other tunnels are not duplicating this behavior.

 

Cause

There are three possible causes to this issue:

  1. Tunnel Monitoring is enabled while there is no IP address configured on the tunnel. Tunnel monitoring use the tunnel IP address as source of tunnel monitoring ICMP packets.
  2. Tunnel Monitoring is enabled while there is no corresponding Proxy-ID for the tunnel IP address and IP address being monitored. For Access Control List (ACL) based IPSec VPN, Proxy-ID pair for the corresponding tunnel IP address and IP address being monitored is needed.
    Note: There is no need for Proxy-ID for tunnel to tunnel IP Address Tunnel Monitoring between Palo Alto Networks firewall.
  3. It is possible this is not an issue and that Palo Alto Networks firewall is just logging normal rekey for multiple tunnels. This is true if rekey interval is very short and there are multiple Proxy-ID pairs.

 

To verify on the Palo Alto Networks firewall use the following CLI commands:

  • Verify IKE debug level
    > debug ike global show
  • Change IKE debug level to debug
    > debug ike global on debug
  • To observe IKE messages
    > tail follow yes mp-log ikemgr.log
  • Return debug level to normal after troubleshooting
    > debug ike global on normal

 

Details

For issue 1: Configure an allocated IP address on the IPSec tunnel, or disable tunnel monitoring if not needed.

For issue 2: Configure Proxy-ID for corresponding tunnel IP address and IP address being monitored, or disable tunnel monitoring if not needed.

For issue 3: Check rekey interval on IKE Phase1 and IKE Phase2.

 

Use the following CLI command to show VPN gateway:

> show vpn gateway

 

  GwID   Name     Peer Address/ID            Local Address/ID           Protocol   Proposals

-------- ----     ---------------            ----------------           --------   ---------

  10     GW-1     1.1.1.1(ipaddr:1.1.1.1)    2.2.2.2(ipaddr:2.2.2.2)    Main       [PSK][DH2][AES256][SHA1] 300-sec     <<== rekey too short

 

> show vpn tunnel

 

TnID Name(Gateway)            Local Proxy IP  Ptl:Port  Remote Proxy IP  Ptl:Port  Proposals

---- -------------            --------------  --------  ---------------  --------  ---------

100  TUN-1:ProxyPair1(GW-1)   192.168.1.0/24    0:0     192.168.31.0/24    0:0     ESP tunl [DH2][AES256][SHA1] 300-sec    <<== rekey too short

100  TUN-1:ProxyPair2(GW-1)   192.168.2.0/24    0:0     192.168.32.0/24    0:0     ESP tunl [DH2][AES256][SHA1] 300-sec    <<== rekey too short

100  TUN-1:ProxyPair3(GW-1)   192.168.3.0/24    0:0     192.168.33.0/24    0:0     ESP tunl [DH2][AES256][SHA1] 300-sec    <<== rekey too short

<output cut>

100  TUN-1:ProxyPair24(GW-1)  192.168.24.0/24   0:0     192.168.54.0/24    0:0     ESP tunl [DH2][AES256][SHA1] 300-sec    <<== rekey too short

100  TUN-1:ProxyPair25(GW-1)  192.168.25.0/24   0:0     192.168.55.0/24    0:0     ESP tunl [DH2][AES256][SHA1] 300-sec    <<== rekey too short

 

Observing the following logs shows the SPI key is being rekeyed every 3mins+. Since there are multiple Proxy-ID pairs on the TUN-1 tunnel, there are frequent rekeys because of the settings lifetime 5mins. The logs appear to be consecutive rekeys and are actually from different tunnels rekeying within the 5mins interval. All multiple Proxy-ID will rekey 5mins and from the logs perspective appears to be too many.

 

To verify, pick the SPI from the tunnel that exhibiting frequent rekey, use match by PEER-VPN-IP-ADDRESS.

> show log system direction equal backward | match 1.1.1.1

2014/02/24 13:43:04 info     vpn     TUN-1 ike-neg 0  IKE phase-2 negotiation is started as initiator, quick mode. Initiated SA: 2.2.2.2[500]-1.1.1.1[500] message id:0x6F845F96.
2014/02/24 13:43:04 info     vpn     TUN-1 ike-neg 0  IKE phase-2 negotiation is succeeded as initiator, quick mode. Established SA: 2.2.2.2[500]-1.1.1.1[500] message id:0x6F845F96, SPI:0xDBE7425F/0xC3D97F6B.

2014/02/24 13:43:04 info     vpn     TUN-1 ipsec-k 0  IPSec key installed. Installed SA: 2.2.2.2[500]-1.1.1.1[500] SPI:0xDBE7425F/0xC3D97F6B lifetime 300 Sec lifesize 128000 KB.

 

Using the following command, choose only logs related to the SPI:

> grep pattern 0xDBE7425F mp-log ikemgr.log

 

Established SA: 2.2.2.2[500]-1.1.1.1[500] message id:0xB6DF139C, SPI:0xDBE7425F/0xC3D97F6B

2014-02-24 13:43:04 [INFO]: ike_pfkey.c:339:sadb_log_add(): SADB_UPDATE ul_proto=255 src=1.1.1.1[500] dst=2.2.2.2[500] satype=ESP samode=tunl spi=0xDBE7425F authtype=SHA1 enctype=AES256 lifetime soft time=300 bytes=0 hard time=300 bytes=0

Installed SA: 2.2.2.2[500]-1.1.1.1[500] SPI:0xDBE7425F/0xC3D97F6B lifetime 300 Sec lifesize unlimited

Deleted SA: 2.2.2.2[500]-1.1.1.1[500] SPI:0xDBE7425F/0xC3D97F6B

2014-02-24 13:46:40 [INFO]: SADB_DELETE ul_proto=0 src=2.2.2.2[500] dst=1.1.1.1[500] satype=ESP spi=0xDBE7425F

2014-02-24 13:46:40 [INFO]: received PFKEY_DELETE seq=0 satype=ESP spi=0xDBE7425F

 

Start: 13:43:04

End: 13:46:40

 

Resolution

Approximately, rekey every 3 mins+ for every tunnel will create what appears to be that excessive rekey is normal. Increase the rekey value to balance or suit requirements.

 

owner: jlunario



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClfICAS&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language