afm ipsec

2 Topics

During 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 remote sites. The only thing common between the two connections is that both remote device is a Cisco ASA. One is an ASA5520 on 7.2(4) and the other one is an ASA5585 on 9.2(4)14. Here are the details of the IPsec configuration: PHASE1 Version:IKE v1 Authentication algorithm:SHA-1 Encryption algorithm:AES256 Perfect forward secrecy/dh-group:MODP1536 Lifetime:1440 Authentication method:PSK Mode:Main NAT Traversal:ON DPD Delay:30 sec Replay window size:64 packets PHASE2 IPsec protocol:ESP Mode:Tunnel Authentication algorithm:SHA-1 Encryption algorithm:AES256 Perfect forward secrecy:MODP1536 Lifetime:1440 It has been verified by both sides multiple times that the configuration is exactly the same. Also, we are the ones using NAT-T. We have an external router where the public ip address is NATed to the F5. The problem is that during ike rekeying some tunnels won't reestablish. Only some will, but not all. For example in one ipsec there are 3 traffic selectors. Traffic is flowing through in all 3 of them when everything is fine. After the rekeying only one will work and we have to clear the whole ipsec to make it work again. What we found so far that the ASAs will start rekeying at 75% of the lifetime (so in our case around 18 hours) https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/81824-common-ipsec-trouble.htmlvpndisc According this document it's not a problem. However, almost always the tunnels won't come up. (There have been a few occasions when for some magical reason they came up but it's pretty rare..) Log from the ASA when rekeying starts at 18 hours. Mar 7 02:50:51 asa %ASA-4-113019: Group = 1.2.3.4, Username = 1.2.3.4, IP = 1.2.3.4, Session disconnected. Session Type: IPSecLAN2LANOverNatT, Duration: 18h:00m:29s, Bytes xmt: 4133553397, Bytes rcv: 2396963220, Reason: IKE Delete Here are the logs from the racoonctl log, as it is too long to paste it here: https://pastebin.com/H39ZbYLS So the conclusion so far is that there is traffic between the peer IPs, even when the problem occurs. The traffic in the IPsec SAs goes back and forth continuously. When the IKE rekey happens the old IKE SA closes and a new one is created and the IPsec SAs are renewed. For a second the traffic in the IPsec SAs breaks but then continues to flow once again. But when the error happens not every IPsec SA reestablishes and we can only see timeouts in the logs. I hope you can help. The clients are a "bit" mad about this issue. Thanks.
Solved
tihi_341714
Mar 14, 2018 Place Technical Forum
2.8KViews
0likes
1Comment
Connection not getting ACK in 3way handshake in IPSec
Hi, We have a minor IPsec problem and I can't seem to wrap my head around it. There a number IPSecs on our F5 and most of them have public IP addresses assigned to them and public peers as well. But this one is using private IP addresses and is going through an MPLS VPN cloud. So something like this: Remote FW <-> Cisco ASR where the other end of the IPSEC is terminated <-> PE router of the MPLS <-> MPLS <-> Another PE <-> Our F5 LTM/AFM device On our end, we have a VLAN configured which floating IP is the one terminating the IPsec. Also, this VLAN is a transit VLAN, an incoming/outgoing interface from/to the MPLS cloud. The traffic from our end goes like this: 10.78.69.140 -> 10.30.0.74:443 The 10.78.69.x subnet is assigned to a forwarding virtual server that can send traffic anywhere, including the IPsec tunnel. So the problem is that the packet goes out but during the 3way handshake we can not see the ACK in the inside VLAN but we can see it in the incoming VLAN. tcpdump from the inside vlan that goes out on the outgoing forwarder: 15:56:24.329348 IP (tos 0x0, ttl 64, id 5505, offset 0, flags [DF], proto TCP (6), length 52) 10.78.69.140.25270 > 10.30.0.74.https: Flags [S], cksum 0xb05f (correct), seq 2546182054, win 26400, options [mss 1320,nop,nop,sackOK,nop,wscale 7], length 0 in slot1/tmm5 lis=/PART_XY/FWVS_XY-OUTSIDE incoming: 15:56:24.333293 IP (tos 0x0, ttl 125, id 28012, offset 0, flags [DF], proto TCP (6), length 52) 10.30.0.74.https > 10.78.69.140.25270: Flags [S.], cksum 0xa0b4 (correct), seq 3594223601, ack 2546182055, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 in slot1/tmm5 lis= So it seems that the for some reason the ACK can't be seen in the VLAN where the traffic was originated from. We've never had this kind of issue with the rest of the IPSec, even if the only difference is the IP address.. I'd appriciate if you could help me. Best regards
tihi_341714
Aug 07, 2018 Place Technical Forum
499Views
0likes
0Comments