Improving AWS / Cisco ASA VPN Instability

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 –

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)

encryption aes
authentication pre-share
group 2
lifetime 28800
hash sha
exit

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

#CustomerGateway

-> 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
frequency 5
exit
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). [1]

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
default-group-policy filter
exit
tunnel-group AWS_ENDPOINT_2 general-attributes
default-group-policy filter
exit

For more information, please refer to the #2: Access List Configuration, #3: IPSec Configuration and #4: VPN Filter in the following documentation –

https://docs.aws.amazon.com/AmazonVPC/latest/NetworkAdminGuide/Cisco_ASA.html