IKE SA expires, but then what?

embedded_guy

Hello everyone! I am relatively new to IPSec/IKE, as I'm an embedded firmware engineer tasked with getting IPSec/Ike working on our VxWorks based cpu.

I apologize in advance for this being a 'general' IPSec/IKE question and not a pfSense question in particular, and if the questions are too elementary! I tried various searches on here to ensure I'm not asking the same thing that was just answered yesterday, but didn't see anything like it… I am simply hoping to draw on some IPSec expertise here, so here goes... ;)

I have managed to get IPSec comms up and running between two of our devices (using wireshark to verify its encrypted), but I've run into a problem with the IKE SAs and the 'lifetime' timer expiring. When it does, the communications just ceases. If I re-initialize the IKE daemon, forcing it to re-read the IKE configuration file (and restart the lifetime timer in the process), communications resumes. It appears there is currently no built-in mechanism to re-intialize or re-negotiate the SAs automatically to keep communications up and running, or most likely, that I have not discovered how to turn that on. :P

Our cpu board is to be used in a SCADA system, which means communications will be expected to operate uninterrupted and without any human intervention indefinitely. I need to implement some means of translating that objective into reality while using IPSec. I have the trivial ability to set the SA lifetimes to a 'very long period', but even then the timers will eventually expire and currently when they do, communications just stays down.

Obviously, I need to learn the basic procedure(s) to re-establish communications whenever say, one side of the communications has died and the other side's DPD closes the tunnel, or the SA lifetimes expire. I'm sure there are many other recovery scenarios I will need to account for, but these are the ones I'm working now.

I've been looking through the Wind River API's regarding IPSec and IKE, but haven't found any mention about a procedure to do this - as if the implied function is for finite-timed connections only. What is ya'lls experience with that?

Any useful hints or methods on where to start would be extremely helpful at this point.

Thanks!

jimp

There are mechanisms in place but IPsec has its quirks when working with different devices. Renegotiation is left up to the initiator, so depending on "who started it" (the tunnel) that is who needs to handle the renegotiation.

When dealing with non-pfSense devices I have often had to set "Prefer old IPsec SAs" under System > Advanced. Can you try to set that and see if there is a difference?

embedded_guy

@jimp:

There are mechanisms in place but IPsec has its quirks when working with different devices. Renegotiation is left up to the initiator, so depending on "who started it" (the tunnel) that is who needs to handle the renegotiation.

When dealing with non-pfSense devices I have often had to set "Prefer old IPsec SAs" under System > Advanced. Can you try to set that and see if there is a difference?

Thanks, I looked at what parameters I have access to configure, and found an IKE sysvar called rekey_passive, and the description says "When an IPSec or IKE SA expires, the original initiator usually initiates a rekeying negotiation. This sysvar is intended for use when interfacing with an IKE implementation that cannot initiate rekeying. For IKE v1 only."

That sounds like what you are referring to, and IKE v1 is the "old IPSec SAs"?

I will play with that! Thanks for the hint!