- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
09-13-2021 05:30 AM
Hi everyone,
I'm trying to setup a route based IPSEC tunnel between my PAN 3020 and Cisco 2900 router. I'm getting a parameter mismatch on on the ipsec lifesize parameter and don't know how to fix it.
The Cisco peer appears to be wanting a lifesize setting of 4608000KB but the PAN won't let you set it that high. I've tried setting it with the equivalent MB setting on the PAN but I'm still getting the mismatch. Does anyone know how to change this setting on the Cisco side? I can't seem to find the right command.
This is what I see on the PAN. I am not the admin for the Cisco router.
Any ideas?
2021-09-10 16:36:10.645 -0500 [PNTF]: { 2: }: ====> PHASE-2 NEGOTIATION STARTED AS RESPONDER, (QUICK MODE) <====
====> Initiated SA: <redacted>[500]-<redacted>[500] message id:0x4B3D3BCC <====
2021-09-10 16:36:10.646 -0500 [PNTF]: { 2: 11}: simultaneous phase-2 rekey request detected, peer is not PANOS. delay processing this new request(isakmp message-id 0x4B3D3BCC).
2021-09-10 16:36:10.646 -0500 [PERR]: { : 11}: lifesize 4608000 KB
2021-09-10 16:36:10.646 -0500 [PERR]: { : 11}: not matched
2021-09-10 16:36:10.646 -0500 [PERR]: { : 11}: no suitable policy found.
2021-09-10 16:36:10.646 -0500 [ERR ]: { : 11}: failed to pre-process packet.
2021-09-10 16:36:10.703 -0500 [INFO]: { 2: }: IKE ISAKMP KEY_DELETE recvd: cookie:490a0356f9c07229:aaa5e1482371a0a4.
98%
09-13-2021 06:29 AM
Thank you @epeeler for posting question.
This is the default value in Cisco IOS: crypto ipsec security-association lifetime kilobytes 4608000
In order to change it, please go to configuration mode, then issue: crypto ipsec security-association lifetime kilobytes <2560-4294967295>
Kind Regards
Pavel
09-13-2021 07:25 AM
Hey @epeeler ,
That is intersting. Up to this point I was living with the impression that lifesize mistmatch should not effect phase negotiation, similar to lifetime.
If lifetime is configured differently on both end of the tunnel, tunnel will be negotiated successfully, but you will experiance some issues with the traffic.
While I agree with @PavelK and you should definately fix the mistmatch, I am little sceptic as this is the actual reason for failing tunnel negotiation. In addition using MB on Palo, should be exactly the same, as the IPsec standard is actually using KB, so in the background Palo should convert the MB and sent the equivalent KB.
Are you sure all other settings matching phase2 settings? You will notice that Palo support CBC and GCM modes for the encryption algorithms, while I am not sure if Cisco is supporting GCM you may want to check if Palo is using CBC.
09-13-2021 06:29 AM
Thank you @epeeler for posting question.
This is the default value in Cisco IOS: crypto ipsec security-association lifetime kilobytes 4608000
In order to change it, please go to configuration mode, then issue: crypto ipsec security-association lifetime kilobytes <2560-4294967295>
Kind Regards
Pavel
09-13-2021 07:25 AM
Hey @epeeler ,
That is intersting. Up to this point I was living with the impression that lifesize mistmatch should not effect phase negotiation, similar to lifetime.
If lifetime is configured differently on both end of the tunnel, tunnel will be negotiated successfully, but you will experiance some issues with the traffic.
While I agree with @PavelK and you should definately fix the mistmatch, I am little sceptic as this is the actual reason for failing tunnel negotiation. In addition using MB on Palo, should be exactly the same, as the IPsec standard is actually using KB, so in the background Palo should convert the MB and sent the equivalent KB.
Are you sure all other settings matching phase2 settings? You will notice that Palo support CBC and GCM modes for the encryption algorithms, while I am not sure if Cisco is supporting GCM you may want to check if Palo is using CBC.
09-13-2021 08:41 AM
First of all, thank you both for taking the time to respond. The issue did indeed end up being a parameter other than lifesize being mismatched. I had not turned on ike debugging on the PAN and so the messages I was seeing in the log while correct, didn't necessarily correspond to each other. Once I enabled detailed debugging I could see what the actual mismatch was which ended up being the hash setting for the phase 2 connection.
Moral of the story here...even though you're seeing log entries for phase 1 and phase 2 negotiation, if you don't turn on debug for ike, you're not getting the full story.
Again, thank you both very much.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!