cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
636
Views
0
Helpful
12
Replies

VPN Tunnel connecting at a unconfigured setting - Phase 1 Timer

Stephen Carter
Level 1
Level 1

OK, so I've got a set of ASA's and we are migrating them to Firepowers, and all seems ok.

In the past we have noticed that for some reason on the ASA's, no matter what you specify as the parameters for phase 1, the rekey timer always connects at 3600 seconds.

We were hoping that when we moved to the Firepowers this issue would 'go away', however on testing we are seeing the following,

which is that on the ASA we have the following configured for IKEv1 - 

Screenshot 2024-04-25 142720.png

And on the firepower we have - 

Screenshot 2024-04-25 142752.png

 So when I run the packet tracer (from the ASA to the Firepower) to test the parameters of the link we see this on the firepower -see highlighted - 

StephenCarter_0-1714052852588.png

So how can this be ? there is no 3600 configured on the firepower - so how can the link be connecting ? 

Is the ASA forcing something on the firepower ? Is this excepted behaviour ? is there any documentation out there that can shed light on this ?

Any help or advice gratefully received - otherwise I can see this being a TAC case.

Regards,

S

1 Accepted Solution
12 Replies 12

MHM

Stephen Carter
Level 1
Level 1

OK, a couple of things - I've updated the text as it wasn't clear as to which end was which.

To the response from MHM...  - well, yes I know the timeout is controlled by the initiator, but the 'thought' was that it was the " first best match" in the configured settings that each device then agrees upon.

So, No, the ASA isn't the responder in this case, and even if it were, it still asks the question - Why is the link rekey timer 'connecting' at 3600 ? when this option isn't on the firepower ?

 

MHM

Hi Stephen, if I understand your question correctly, you are asking why the FTD is using a lifetime value that is not configured on itself? if so, the answer is because the lifetime value can have a different value on both peers, and when they start the negotiation they will agree on the lowest value. In fact, as you shared in the screenshots the FTD has a higher value, however, it uses the lower value that is configured on the remote peer.

Aref, OK, that I can understand, but when you have 50 VPN's connecting to a device, and some (as they are customers) want to connected at 86400, some at 28800 and you get the picture - you are basically saying that that goes out of the window and the link will connect at the first configured option ? so why have a list and the ability to have multiple settings when on one for each 'variable' is needed ?

Aref,

Thanks for the link, wish I'd found that beforehand.

I do have another question - in general a vpn link is made up of enc. hash, timer etc - apart from the rekey timer (as mentioned above) are there any other 'settings' that can be 'imposed' on a link when 'handshaking' ?

I referring to the DH group option, we have a link from the Firepower to AWS, and the end customer stated they wanted to use DH grp 5, yet when the handshake took place - the link connects at DH grp 14. Now at our end we have 5 and 14 configured (see firepower screenshot above) - so any ideas ? or is the customer wrong ?

You're very welcome Stephen. The only value that can be different is the lifetime, all the other values hash, authentication type, encryption, and DH must match between the peers, otherwise the negotiation will evaluate the next policy, and if there is no match the tunnel won't be established.

Interesting they want to move away from DH 14 and go with DH 5, but regardless, if they said they wanted to move to DH 5 and the tunnel still gets established with DH 14 then they would most likely still have the DH 14 configured on a policy that is being elected during the negotiation. Otherwise as mentioned before the tunnel won't come up.

Also, I see on your Firepower you have multiple policies pretty much exactly the same and the only difference is the lifetime. You wouldn't need all those redundant policies, one is enough and as mentioned before, the lower lifetime value will be used.

Feel free to ask any further questions, I'm happy to help.

Aref,

No further questions - what you have posted in this question has been very gratefully received - it will be put to good use.

Glad I could help, Stephen.

 

MHM

MHM