I'm seeing the following "Session disconnected" message on the the local PIX(7.0) VPN peer which has PFS (DH-Group 2) enabled.
Jun 20 15:36:52 192.168.1.1 Jun 20 2008 15:36:52 pix : %PIX-7-715077: Pitcher: received key delete msg, spi 0x85e0312a
Jun 20 15:36:52 192.168.1.1 Jun 20 2008 15:36:52 pix : %PIX-7-715077: Pitcher: received key delete msg, spi 0x60f647fd
Jun 20 15:36:52 192.168.1.1 Jun 20 2008 15:36:52 pix : %PIX-4-113019: Group = 220.127.116.11, Username = 18.104.22.168, IP = 22.214.171.124, Session disconnected. Session Type: IPSecLAN2LAN, Duration: 2h:15m:37s, Bytes xmt: 67640, Bytes rcv: 536552, Reason: User Requested
From RFC 2409, I've found the following with regard to PFS.
"Perfect Forward Secrecy (PFS) of both keying material and identities is possible with this protocol. By specifying a Diffie-Hellman group, and passing public values in KE payloads, ISAKMP peers can establish PFS of keys-- the identities would be protected by SKEYID_e from the ISAKMP SA and would therefore not be protected by PFS. If PFS of both keying material and identities is desired, an ISAKMP peer MUST establish only one non-ISAKMP security association (e.g. IPsec Security Association) per ISAKMP SA. PFS for keys and identities is accomplished by deleting the ISAKMP SA (and optionally issuing a DELETE message) upon establishment of the single non-ISAKMP SA. In this way a phase one negotiation is uniquely tied to a single phase two negotiation, and the ISAKMP SA established during phase one negotiation is never used again."
With this explanation does it mean that when PFS is enabled, ISAKMP rekeying cannot be done without deleting the session leading to a service disruption?
If at all possible, is there a way to avoid this disruption while PFS being activated?
Thank you for your time taken to explain this behavior.
I would interpret this as "each" of the two unidirectional IPSec SAs is negotiated via separate (perhaps non-concurrent) bi-directional ISAKMP SAs.
New IPSec SAs would be negotiated prior to expiration of the pre-existing SAs, and if no ISAKMP SA existed between the peers, one would be initiated/negotiated to facilitate a channel through which the IPSec SAs could be negotiated.
A tunnel can be up with established IPSec SAs, and traffic can traverse the tunnel in the absence of an ISAKMP SA, so I see no reason for a service disruption.
Are you actually experiencing service interruptions, or are you just expressing concern regarding messages that you have observed?
Were new IPSec SAs negotiated (to sustain the tunnel) prior to the deletion of the specific IPSec SAs referenced in the log messages (e.g.: "Pitcher: received key delete msg, spi 0x85e0312a"), or are you stating that no IPSec SAs remained after these were deleted, and that no ESP tunnel existed from that point forward?
On a PIX, is the "Session disconnected" message an acknowledgement that a pair of IPSec SAs are being deleted from the database, or that no IPsec SAs remain in the database for the specific peers?
If you are experiencing service interruptions, and you believe the cause relates to the use of PFS, I would remove the PFS parameter from the policy and attempt to prove whether it is or is not relevant.
I have PFS configured as part of IPSec policy (in the crypto map) for our IPSec + GRE tunnels, and do not see any service interruptions as a result. If PFS normally resulted in a service interruption, no one would be using it.
Would you explain what you mean when referring to a "rekey margin"? IOS is my reference point, and I'm not familiar with such a parameter.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :