You are on page 1of 4

Site-to-Site IPSec Excessive Rekeying on

Only One Tunnel on System Logs


116260
Created On 09/25/18 19:50 PM - Last Modified 05/31/23 21:39 PM
VPNS
PAN-OS
NEXT-GENERATION FIREWALL
STRATA

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.

You might also like