AWS VPN Cisco ASA and SLA Monitor
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.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:
! In order to keep the tunnel in an active or always up state, the ASA needs to send traffic to the subnet ! defined in acl-amzn. SLA monitoring can be configured to 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. ! A possible destination for the ping is an instance within the VPC. For redundancy multiple SLA monitors ! can be configured to several instances to protect against a single point of failure. ! ! The monitor is created as #1, which may conflict with an existing monitor using the same ! number. If so, we recommend changing the sequence number to avoid conflicts. ! sla monitor 1 type echo protocol ipIcmpEcho sla_monitor_address interface outside_interface frequency 5 exit sla monitor schedule 1 life forever start-time now
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.
Why do AWS docs suggest to use the SLA monitor?
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
What is considered interesting traffic?
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.
Step 1: Defining Interesting Traffic
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):
crypto map amzn-vpn-map 1 match address acl-amzn access-list amzn-filter extended permit ip vpc_subnet vpc_subnet_mask local_subnet local_subnet_mask
What should you use as the SLA Monitor target?
From the configuration above, there are 3 recommendations for a good SLA monitor target:
- This traffic needs to be sent to a target that will return a response.
- A possible destination for the ping is an instance within the VPC.
- 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.
blog comments powered by Disqus