As part of my day to day duties as a “Systems Administrator”, I configure site-to-site VPN tunnels from my company’s hosted devices, to remote endpoints of all types. The most common scenario being IPSec VPN tunnels, with the endpoints on my side being a Fortigate and Cisco ASA devices. Our team has done well over the years to establish policies and procedures, with a standard VPN form to make the setup of these tunnels rather elementary. It’s easy and mostly painless.

Raise your hand if setting up VPN tunnels is your idea of fun? Several emails back and forth, complicated, and the more frustrating the better, right? Nobody? Bueller? So – quick and painless sounds good right? Well, the folks over at AWS either skipped the “work smarter not harder” life lesson, or didn’t get my memo on “quick and painless site-to-site VPN setups”©, which leads me to my post today.

Today I’d like to share with everyone my experience with setting up redundant VPN tunnels from a Cisco ASA 5500 series device on my side, to Redundant Amazon Virtual Gateways.

You can find the official Amazon documentation on this configuration here, which is quite helpful:

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

You can also see there are quite a few threads online about this, so it seems to be a fairly common problem:

https://www.google.com/search?q=cisco+ASA+Amazon+IPSec&ie=utf-8&oe=utf-8#q=cisco+ASA+Amazon+IPSec+P2+error

There are a few gotchas in this configuration. Specifically in this post I address three, and specifically with the VPN Tunnel type. Here are the things I ran into that will hopefully help others in setting up their HA AWS VPN tunnels.

Let’s go.

1 – Thou shalt use AES-128 on the IPSec Proposal, not 256 even though it is 2015.

All of our tunnels use 256 in every other case, so this caught me off guard at first. The documentation does not explicitly say 128bit, it simply says AES. The 128-bit is a static value on the Amazon side, unfortunately. Perhaps this is the case to allow for more endpoint flexibility, in regards to older models. Perhaps they are just having fun with us? :)

2 – In your access list, make sure thou are only using a single extended permit statement. It will probably look like this:

access-list INTERFACE cryptomap_XX extended permit ip any 172.31.0.0 255.255.0.0

Where INTERFACE = public or whichever interface
Where XX = crypto map policy number

This applies to both sides. You’ll have to use networks, as opposed to several individual entries. Lock down access via policies. Don’t use multiple /32 entries. If you do, expect failure. Make sure both sides match.

3 – Most important! Thou shalt change the VPN tunnel type FROM Bidirectional, TO Initiate-Only!

It took me quite a while to figure out. If you search Google, there are tons of threads on VPN IPSec and Phase 2 problems to ASA remote endpoints. This golden forum post below is what helped me finally figure it out. As you can see, many many people have problems with this:

https://forums.aws.amazon.com/thread.jspa?threadID=141058

“If you are getting those errors for “AWS_ENDPOINT_1” then try adding the following command to your crypto map settings:

crypto map map-name seq-num set connection-type originate-only

This will force the ASA to reject initiation requests from us. As we still send 0.0.0.0/0 so this will never match thus cause tunnel failures.”

The client configured their side properly, but the Amazon virtual device sends quad 0’s no matter what you place in your network settings. Again, this is probably to comply with older devices, or simple configs to work with a wide audience, and the setting is static! I’m just not doing quad 0’s, sorry AWS dudes.

I have photographic proof this is indeed true:

quad-zero-final

So, what does originate-only mean, compared to bidirectional? Here are the Cisco definitions of the tunnel types:

bidirectional—This specifies that this peer can accept and originate connections based on this crypto map entry. This is the default connection type for all Site-to-Site connections.

originate-only—This specifies that this peer initiates the first proprietary exchange in order to determine the appropriate peer to which to connect.

So – my ASA will originate the connection to AWS, not the other way around. This is key as we know Amazon will just spout out quad 0’s at us if it originates and that is just… the worst.

The config for originate-only looks like this:

crypto map MAP_NAME XX set connection-type originate-only

If you created the tunnel in the ASDM, you can find the crypto map name if you know the priority, with a command like this:

ASA# sh run crypto | incl 12

crypto map publicnew10_map 12 match address public_cryptomap_10
crypto map publicnew10_map 12 set pfs
crypto map publicnew10_map 12 set connection-type originate-only
crypto map publicnew10_map 12 set peer x.x.x.x
crypto map publicnew10_map 12 set transform-set ESP-AES-128-SHA
crypto map publicnew10_map 12 set security-association lifetime seconds 3600

It looks like this in the ASDM:

originate only

Now I am aware of setting multiple peers for the same tunnel. You can find out how to do this here:

http://www.cisco.com/c/en/us/support/docs/security/pix-500-series-security-appliances/67912-pix2pix-vpn-pix70-asdm.html

However, I tried setting it up the multiple peer with a tunnel map for the secondary per Cisco documentation, and it did not work in my scenario. YMMV. If I get another one of these in future, I’ll try it in a single tunnel config, but for now it is working properly as only the active node of the Amazon VPN virtual appliance handles requests.

So there ya go, if Google brought you here, I hope this post has helped you with your ASA to AWS HA VPN tunnel config and the quad 0 nightmare :)

Any thoughts you want to share? Did my post help you or am I way off base? I always love comments.

Thanks,
Gabe

1 Comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.