07-07-2012 11:02 AM - edited 07-07-2012 11:03 AM
I have an SRX220 that has sit-to-site vpns to several PIX515e's. Just one of them have a problem that the vpn drops after a while. I assume that its failing to rekey.
The ipsec sa's for that vpn show a kilobyte lifetime counter as well as a second timer. I have not configured kilobyte counters so I don't understand that.
localadmin@gateway-hb1> show security ipsec security-associations node0: --------------------------------------------------
------------------------ Total active tunnels: 3 ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway <131074 ESP:3des/sha1 e93ec75b 17696/unlim - root 500 IP! >131074 ESP:3des/sha1 dfde9453 17696/unlim - root 500 IP! <131073 ESP:3des/sha1 c7ee08e8 19331/ 4593709 - root 500 IP2 >131073 ESP:3des/sha1 4bd41551 19331/ 4593709 - root 500 IP2 <131075 ESP:3des/sha1 8022cbd1 27028/unlim - root 500 IP3 >131075 ESP:3des/sha1 2c44fe91 27028/unlim - root 500 IP3
IP1, IP2, and IP3 are all cisco PIX's wiit similar configurations.
In the SRX IKE traceopts file I see frequent messages like...
Jul 7 17:08:23 [IP0 <-> IP2] Received IPSec SA lsize update message for Tunnel Id = 131073; In-spi = 0xc7ee08e8, Out-spi = 0x4bd41551, SA lifesize remaining = 4593752kb
I think that this means that the PIX is updating its peer (the SRX) with the current lifetime counts. I don't know why its doing that.
I imagine that the PIX is misconfigured to use kilobyte lifetime counter, but I don't see how.
crypto ipsec transform-set strong-encr-set esp-3des esp-sha-hmac ... crypto map mediabyte-map 17 match address MATCH-TO-HB crypto map mediabyte-map 17 set peer IP0 crypto map mediabyte-map 17 set transform-set strong-encr-set ... crypto isakmp policy 20 authentication pre-share encryption 3des hash sha group 2 lifetime 86400 crypto isakmp policy 65535 authentication pre-share encryption 3des hash sha group 2 lifetime 86400 ... tunnel-group HBPUBIP type ipsec-l2l tunnel-group HBPUBIP ipsec-attributes pre-shared-key <secret> isakmp keepalive threshold 60 retry 2 ...
07-08-2012 07:21 AM
The PIX default lifetimes are 28,800 seconds (eight hours) and 4,608,000 kilobytes (10 megabytes per second for one hour).
Assuming that the particular crypto map entry does not have lifetime values configured, when the PIX Firewall requests new security associations it will specify its global lifetime values in the request to the peer; it will use this value as the lifetime of the new security associations.
Try the following on the PIX to disable the traffic volume lifetime.
crypto ipsec security-association lifetime kilobytes disable
07-08-2012 08:13 AM
Wonderful. That clears up where the kilobytes come from.I actually looked at the SRX config to see if I could explicitly disable the kilobyte count but I did not look at the PIX config for the same. It turns out that that was just a symptom of my problem anyway.
I found a small difference in the proxy ID on the PIX and SRX. It seems that when the PIX initialed the VPN, the SA's were created well enough that it worked. But when they rekeyed, the SRX ended up with two sets of SA's. The set that it initialted had no kilobyte limit, but the set that the PIX initiated had a kilobyte limit. The real problem was that because of the proxy D mismatch, the SA's did not match depending on which side initiated.
07-08-2012 10:00 AM
From Cisco IPSec Configuration Guide
"When the PIX Firewall receives a negotiation request from the peer, it will use the smaller of either the lifetime value proposed by the peer or the locally configured lifetime value as the lifetime of the new security associations"
This was probably causing your 2 sets of SA, one for the PIX initation and one for the SRX initation.