cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1359
Views
0
Helpful
3
Replies

IPSec Tunnels fail after firmware upgrade

steinbackj
Level 1
Level 1

Good day to whomever reads this.

Issue: After an upgrade of firmware, redundant IPSec tunnels are bouncing.

Hardware:

Local = Cisco ASA5505

Remote = FortiGate 100D

Background:

We terminate 3 IPsec VPN tunnels from 2 Cisco ASA5505's to a single Fortigate100D. One the relevant ASA, we have redundant tunnels built in a failover configuration using sla monitor. This had been working until recently when I upgraded firmware on the Cisco ASA5505 from 9.12 to 9.24. I did this for two ASA's that terminate to the Fortigate100D. Upon finishing the upgrade, the stand-alone tunnel between the ASA and the Fortigate came up successfully and is stable. However, the tunnels between the relevant ASA and the Fortigate continue to fight with one another for dominance and neither established a stable connection. I can see that Phase 1 is successful and the monitoring on the Fortigate side shows the tunnel up briefly, but the tunnel is immediately torn down as if it tries to fail over to the secondary tunnel. This process continues to happen in a repeating loop.

If I disable the secondary tunnel, the primary tunnel stays up and presents no issues. This will work as a manual failover, but our preference is to have the redundancy. We have since attempted to roll back to firmware image 9.17, but the behavior repeats itself. I have discount double-checked the configs and everything matches on both ends. My next thought is to roll back to original code 9.12 but at this point I'm not sure it will solve anything. I have not tried to reboot the Fortigate, which I've seen resolve tunnel issues in the past, but not sure I'm ready for that step yet since there is the tunnel to a different ASA that has been stable. 

sla monitor schedule 1 life forever start-time now
crypto ipsec ikev1 transform-set ESP-AES128-SHA esp-aes esp-sha-hmac
crypto ipsec security-association pmtu-aging infinite
crypto map vpn 10 match address vpn_hills
crypto map vpn 10 set peer Fortigate(IP redacted)
crypto map vpn 10 set ikev1 transform-set ESP-AES128-SHA
crypto map vpn 10 set nat-t-disable <----------------------I believe this had been enabled in the beginning but we removed it because it's not needed.
crypto map vpn interface mediacom
crypto map dsl 10 match address vpn_hills
crypto map dsl 10 set peer Fortigate (IP redacted)
crypto map dsl 10 set ikev1 transform-set ESP-AES128-SHA
crypto map dsl 10 set nat-t-disable
crypto map dsl interface outside
crypto ca trustpool policy
crypto ikev1 enable outside
crypto ikev1 enable mediacom
crypto ikev1 policy 10
authentication pre-share
encryption aes
hash sha
group 5
lifetime 86400
!
track 1 rtr 1 reachability

no vpn-addr-assign dhcp

group-policy RA-VPN-Policy internal
group-policy RA-VPN-Policy attributes
dns-server value 10.0.10.51
vpn-tunnel-protocol ikev1
split-tunnel-policy tunnelspecified
split-tunnel-network-list value vpn_ra
default-domain value domain1.com
split-dns value domain1.com domain2.com
split-tunnel-all-dns disable
user-authentication enable
address-pools value vpnpool
username admin password (redacted) encrypted
tunnel-group Foritgate (IP redacted) type ipsec-l2l
tunnel-group Foritgate (IP redacted) ipsec-attributes
ikev1 pre-shared-key *****
tunnel-group Cisco type remote-access
tunnel-group Cisco general-attributes
default-group-policy RA-VPN-Policy
tunnel-group Cisco ipsec-attributes
ikev1 pre-shared-key *****

  Attached is the output from a diag debub on the fortigate.

"Washington" is the primary tunnel. "Washington2" is the secondary. This debug was capture with both tunnels enabled on the fortigate side. 

Let me know if you'd like some more information. Thanks in advance! 

3 Replies 3

I originally upgraded it to 924-8-k8, which caused this behavior so I stepped down one version to 917-4-k8.

And did that resolve the issue?