Asa Ip Sla

1/7/2022by admin
ResponderAsa ip sla

Similar to Cisco's ASA IP SLA, policy-based redirection redundancy requires the determination of the reachability or unreachability of the active next hop and the other configured next hops. This feature can use ARP, NDP or Ping checking to make the determination. Here’s what the IP SLA configuration looks like: R1#show running-config begin ip sla ip sla 1 icmp-echo 192.168.12.2 frequency 10 ip sla schedule 1 life forever start-time now. It’s a simple configuration where R1 will keep sending ICMP echoes to R2 forever. To combine IP SLA with EEM, we’ll need to track it somehow.

08 April 2013 Joe Chan

2015-01-29 Updates: Setting up SLA monitors to the 169.254.x.x addresse(s) and the VPC default gateway at the base of the VPC network range “plus one” (i.e. 10.0.0.1 for 10.0.0.0/16 networks) is no longer recommended.

When configuring the AWS VPC VPN with a Cisco ASA, Amazon recommends that you configure SLA monitoring.

In the pregenerated Cisco ASA configuration downloaded from the AWS VPN Management console (In your AWS VPC Management Console, click on VPN Connections, Right Click on your VPN connection, and click Download Configuration), you’ll see something similar to the example config. In the config, you may see some lines like this:

Asa

Per the Troubleshooting Cisco ASA Customer Gateway Connectivity doc, this is to keep the IPsec tunnel active:

In Cisco ASA, the IPsec will only come up after “interesting traffic” is sent. To always keep the IPsec active, we recommend configuring SLA monitor. SLA monitor will continue to send interesting traffic, keeping the IPsec active.

From this doc, the SLA Monitor feature doesn’t appear to be designed specifically to keep IPsec tunnels up, but the attributes in bold below seem to make it a perfect tool of choice (rather than setting up another device specifically for this purpose).

IP SLAs uses active traffic monitoring—the generation of traffic in a continuous, reliable, and predictable manner—for measuring network performance

From this Cisco press article, it’s traffic that matches the ACL applied to the crypto map:

Step 1: Interesting traffic initiates the IPSec process—Traffic is deemed interesting when the IPSec security policy configured in the IPSec peers starts the IKE process.

AsaAsa Ip Sla

Step 1: Defining Interesting Traffic

Ip Sla Tracking Asa

Determining what type of traffic is deemed interesting is part of formulating a security policy for use of a VPN. The policy is then implemented in the configuration interface for each particular IPSec peer. For example, in Cisco routers and PIX Firewalls, 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, and deny statements can be used to indicate that the selected traffic must be sent unencrypted. With the Cisco Secure VPN Client, you use menu windows to select connections to be secured by IPSec. When interesting traffic is generated or transits the IPSec client, the client initiates the next step in the process, negotiating an IKE phase one exchange.

On the ASA, it’s comes from lines like this in the config (note that by default the access-list line is commented out):

From the configuration above, there are 3 recommendations for a good SLA monitor target:

  1. This traffic needs to be sent to a target that will return a response.
  2. A possible destination for the ping is an instance within the VPC.
  3. For redundancy multiple SLA monitors can be configured to several instances to protect against a single point of failure.

As such, I would recommend configuring 2 VPC instances that respond to pings from the ASA along with 2 SLA monitors, one targeting each of the instances.

Please enable JavaScript to view the comments powered by Disqus.blog comments powered by

Asa Ip Sla

Disqus
Comments are closed.