Forum Discussion
tihi_341714
Nimbostratus
NimbostratusDuring ike rekey in a s2s IPsec config some tunnels won't reestablish
Hi,
I would like some help regarding an IPsec problem we are experiencing in our DC.
We have a few different route domains in our F5. Two different RDs are configured for IPSec to two different...
The first thing to note is that I have no idea how well the ASA 7.2(4) software version works, there could be bugs there, but let's assume that this isn't peer specific.
Re-key problems like this can occur when NAT Detection did not actually happen during the phase 1 SA setup. So ensure that NAT detection is enabled on all peers. For NAT-D to work, both peers have to agree on one of the NAT RFCs or drafts. You can tell that NAT-D worked, if your ESP traffic is encapsulated in UDP port 4500.
By the way, the soft lifetime on an SA is 80%, upon which the BIG-IP will attempt to create a new SA, but the old SA will live until the hard lifetime expires.
The ASA, at least on version 9.x, has a tendency to rip down all the tunnels during an SA delete but not find the time to notify the peer about all those prematurely deceased SAs. Most vendors that see a delete (not an expire) on a phase 1 SA will tear down all the phase2 as well. The BIG-IP does not do that, it assumes (correctly) that the phase 2 SA is still up. The upshot is that if the tunnels are generally initiated on the BIG-IP side, the SA will remain in use by the BIG-IP until it determines to renew that SA.
If traffic was frequently initiated on either side of each (phase 2) tunnel/selector, you probably wouldn't notice the issue. Setting up a permanent PING on both sides for every tunnel/selector may actually work-around the issue if this is what you're seeing.
It's worth noting that the problem you've described has consistently been reported by customers using an ASA peer, it doesn't seem to happen with other vendors. There are some bugfixes in place that take a more aggressive approach to deleting SAs so as to avoid the described scenario, but I do not believe all the required code is in a mainstream release (current is 13.1) yet. F5 Support could help you there.
The first thing to note is that I have no idea how well the ASA 7.2(4) software version works, there could be bugs there, but let's assume that this isn't peer specific.
Re-key problems like this can occur when NAT Detection did not actually happen during the phase 1 SA setup. So ensure that NAT detection is enabled on all peers. For NAT-D to work, both peers have to agree on one of the NAT RFCs or drafts. You can tell that NAT-D worked, if your ESP traffic is encapsulated in UDP port 4500.
By the way, the soft lifetime on an SA is 80%, upon which the BIG-IP will attempt to create a new SA, but the old SA will live until the hard lifetime expires.
The ASA, at least on version 9.x, has a tendency to rip down all the tunnels during an SA delete but not find the time to notify the peer about all those prematurely deceased SAs. Most vendors that see a delete (not an expire) on a phase 1 SA will tear down all the phase2 as well. The BIG-IP does not do that, it assumes (correctly) that the phase 2 SA is still up. The upshot is that if the tunnels are generally initiated on the BIG-IP side, the SA will remain in use by the BIG-IP until it determines to renew that SA.
If traffic was frequently initiated on either side of each (phase 2) tunnel/selector, you probably wouldn't notice the issue. Setting up a permanent PING on both sides for every tunnel/selector may actually work-around the issue if this is what you're seeing.
It's worth noting that the problem you've described has consistently been reported by customers using an ASA peer, it doesn't seem to happen with other vendors. There are some bugfixes in place that take a more aggressive approach to deleting SAs so as to avoid the described scenario, but I do not believe all the required code is in a mainstream release (current is 13.1) yet. F5 Support could help you there.