Cisco Firewall:: ASA 5510 Failover With IP SLA Monitor? Can I run Cisco ASA failover with dual ISP run active/standby configuration and SLA monitor to monitor the primary ISP gateway and failover to the secondary gateway but not failover to the failover firewall unless an actual event occurred that required a ASA failover?
- Symptom: As of now, SLA monitor doesn't have the functionality to monitor any IP over the VTI interfaces on ASA but only physical interfaces. This could prove useful if we want to track an IP address over the Primary tunnel to fail over to backup tunnel when using static routes. Conditions: -ASA running 9.7(1).
- Policy based IPSEC tunneling is probably the most widely used technique to get two offices to communicate securely (at least in the SMB Market). Today I’m going to discuss how you can configure two ASA’s to failover to their secondary WAN, and then have their tunnels fail over as well.
This post describes how to configure a Cisco ASA firewall for redundant/dual ISP connections, using the IP SLA and track features. IP SLA will be configured in conjunction with the track feature to monitor the connection/reachability to the Primary ISP connection. In the event of failure, the primary default route will be removed and will failover to a backup route.
Configure the 2 outside interfaces, in this case PRIMARY and SECONDARY will be used to identify the outside interfaces.
Create nat rules for traffic routed out of the primary and secondary interfaces.
Create an SLA monitoring process, which will periodically send ICMP echo requests to the IP address of the next hop (ISP router) and from the primary interface.
Schedule the SLA process to start immediately with a lifetime of forever.
Create a track ID, the “rtr” references the SLA ID. The track ID will be used in conjunction with static default route.
Define a default route via the PRIMARY interface, referencing the track object.
Create a backup default route via the SECONDARY interface with an administrative distance greater than the tracked default route.
From a test computer ping an IP address on the internet, e.g. 220.127.116.11
Confirm traffic is being routed out of the PRIMARY interface
Confirm that traffic is hitting the correct NAT rule
Confirm the status of the IP SLA enter the command show sla monitor operational-state, ensure timeout equals FALSE.
Confirm that reachabilty of the track is Up, use the command show track
Shutdown the interface of the PRIMARY interface
Confirm the status of the reachability of the track is Down
Confirm the default route is now via the SECONDARY interface.
Confirm traffic is natted by the correct NAT rule
Re-establishing connectivity via the PRIMARY interface will result in the default route via the PRIMARY interface being installed in the routing table.
If you are experiencing any instability in regards to a VPN connection between your corporate datacenter and AWS, consider the following (received from AWS Support) if you are using Cisco ASAs to establish the VPN connection to AWS.
-> From looking at the logs, following are the suggested changes –
Asa Ip Sla
1. I am seeing Phase 1 re-keys every hour. Instead Phase 1 Lifetime should be configured as 28800 seconds, so re-key every other 8 hours. So the IKE configuration would look something along these lines –
crypto isakmp policy 10* *—–> Priority would differ in your configuration, and determines the priority of the policy in ISAKMP Negotiations (1st match will be picked)
Please ensure that the policy that matches the first has lifetime configured as 28800 seconds.
2. There could be multiple reasons for the tunnel to go down. One of the common reasons for the VPN tunnels – specifically policy-based to fail is due to lack of interesting traffic on the tunnels. The interesting traffic means traffic that will be encrypted. With Policy based VPNs – Interesting traffic initiates the IPSec process – Traffic is deemed interesting when the IPSec security policy configured in the IPSec peers starts the IKE process. For example – On the Cisco ASA device, access lists are used to determine the traffic to encrypt. The access lists are assigned to a crypto policy such that permit statements indicate that the selected traffic must be encrypted.
-> To keep this tunnel in always up state, it is required that there should be any interesting traffic (meaning the interesting traffic that will be sent encrypted to the endpoint) that is initiated from the customer side (on-premises) to AWS network (VPC). In this case, you will need to keep the continuous pings running specifically from on-premises host to an EC2 instance. If you do not want to run continuous pings, you can run pings at an interval of 5 seconds and that would be enough as well to keep the tunnel UP.
For more information –
Troubleshoot VPN Tunnel Inactivity or Instability – https://aws.amazon.com/premiumsupport/knowledge-center/vpn-connection-instability/
-> Important Note – AWS VPN Endpoints do not have the ability to bring up the tunnel nor does traffic from the VPC towards the remote network or hosts. It is recommend that you have interesting traffic being initiated from your on-prem network over the VPN tunnel to ensure the tunnel is always UP.
For reference – https://docs.aws.amazon.com/AmazonVPC/latest/NetworkAdminGuide/Introduction.html
-> On Cisco ASA – you can even configure SLA monitor – it basically send pings to a destination in the subnet and will keep the tunnel active. This traffic needs to be sent to a target that will return a response. This can be manually tested by sending a ping to the target from the ASA sourced from the outside interface. For reference, I am sharing the configuration details for SLA monitor to work –
a. SLA monitor configuration –
sla monitor 1
type echo protocol ipIcmpEcho sla_monitor_address interface outside_interface
sla monitor schedule 1 life forever start-time now
icmp permit any outside_interface
sla_monitor_address – EC2 instance – Private IP
b. For SLA Monitor to work, an update is required to Access-list configuration –
Configure the policy to allow “any” network (0.0.0.0/0) from behind the customer gateway to the VPC CIDR – this will permit any traffic to VPC, that includes the on-prem subnet and the Outside interface of Cisco ASA (for SLA monitoring to work)
access-list acl-amzn extended permit ip any vpc_subnet vpc_subnet_mask
Please note – You must use a single access-list entry for accessing the VPC range. Because, when using a policy-based VPN configuration, AWS limits the number of security associations to a single pair (one inbound and one outbound). 
c. Implement a traffic filter on the customer gateway to block unwanted traffic to the VPC –
VPN Filters –
access-list amzn-filter extended permit ip vpc_subnet vpc_subnet_mask local_subnet local_subnet_mask
access-list amzn-filter extended deny ip any any
group-policy filter internal
group-policy filter attributes
vpn-filter value amzn-filter
tunnel-group AWS_ENDPOINT_1 general-attributes
tunnel-group AWS_ENDPOINT_2 general-attributes
Cisco Asa Ip Sla Responder
For more information, please refer to the #2: Access List Configuration, #3: IPSec Configuration and #4: VPN Filter in the following documentation –