| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
We treat these as if we concluded the rekeying, the active ike-rekey task
will handle the collision afterwards.
|
| |
|
|
|
| |
RFC 7296 explicitly says we SHOULD reply as usual and forget about our
own close request.
|
| |
|
|
|
|
|
|
|
| |
This makes handling such IKE_SAs more specifically compared to keeping them
in state IKE_CONNECTING or IKE_ESTABLISHED (which we did when we lost a
collision - even triggering the ike_updown event), or using IKE_REKEYING for
them, which would also be ambiguous.
For instance, we can now reject anything but DELETES for such SAs.
|
| |
|
|
|
| |
The old identifiers did not use a proper namespace and often clashed with
other defines.
|
| | |
|
| |
|
|
|
| |
This avoids deleting IKE_SAs during reauthentication (without
trying to reestablish them).
|
| |
|
