Site-to-site VPN using IKEv2 - how?

I’ve seen this link posted in a dozen places since it was announced:

https://aws.amazon.com/about-aws/whats-new/2019/02/aws-site-to-site-vpn-now-supports-ikev2/

…I get it, but this news post seems to literally be the total of documentation on the subject, toward the aim of step by step configuring it. That post goes on to say, “You can control the IKE version to use by updating your customer gateway device’s configuration and the AWS side endpoint will negotiate the session using the same protocol”, but this is just a general description, and does not explain how, specifically, one forces or otherwise configure IKEv2 _in opposition to v1_. I’ve tried looking for further details in various AWS VPC guides, and so on, and haven’t had luck in that regard.

I’ve tried things like creating a completely new customer gateway, virtual private gateway, and then a new site-to-site VPN connection (or JUST a new site-to-site VPN connection as the above statement suggests should be sufficient). No combination of doing any of these things seems to yield a downloadable configuration that contains an _actual_ IKEv2 configuration. (It may be that I’m trying the wrong tactic in hoping that I’ll get a working configuration by that route, since the news post does hint that you have to take the existing IKEv1 configuration and mangle it somehow to work with v2, but not what changes are needed for that to happen.)

So, my question is this. Other than the acknowledgement that AWS has said IKEv2 *should* work, does anyone have a provable configuration that *does* work? Was there any signal in the initial site-to-site VPN creation process that clearly indicates that your IKEv2 configuration would work (such as, the configuration download specifies it) – or is the downloadable configuration the same as it always has been, ready for IKEv1 cut-and-paste, and you had to do manual configuration modifications after the fact to make it work with IKEv2? If so, what changes did you have to make?

Any insight appreciated - I’m stumped here.

There’s not much in the documentation or announcement that states how exactly to get IKE v2 working, but it’s clear that they don’t provide the configuration or any further information. It does stipulate you’d need to modify the configuration on your own, so at least there’s that.

I suspect once they roll out IKE v2 to existing connections, they’ll eventually start updating configuration generators.

I don’t have any spare devices handy at the moment, but I’ll have a Fortigate available tomorrow and I can walk through a configuration to see if it’ll work with IKE v2. What type of device are you looking to configure?

I had read that exact release about a month ago when we were standing up some new tunnels. Tried v2 with no luck and had to get the tunnels up.

We have enterprise support so I’d love to know what’s up. Their tunnel configurations are “strange” to say the least. The entire fact that sa can’t be established from aws side is just mind blowing to me :man_shrugging:

Edit to note that we’re fresh tunnels in a fresh new vpc with a brand new gateway after their release that OP linked.

I really don’t like how opaque their configs are. I have to hope they support all my preferred encryption and integrity option as well as DH groups. Once I exported the config for an ASA using a new customer gateway and new site-to-site IPsec tunnel, I knew it wouldn’t work b/c they didn’t even provide IKEv2 pre-shared keys. I know they could easily use the same key for IKEv1 and IKEv2, but their automated config didn’t even indicate IKEv2 keys, which would be required on Cisco equipment.

I partially succeeded with the setup.

When you specify:

keyexchange=ikev2

in your strongswan config, it will use ikev2. Even if ipsec.1 is specified on the AWS site.

Connections:

Tunnel2: %any…3.x.x.x IKEv2, dpddelay=10s

I still work on getting the full connection going, but this is out of scope for this discussion. Seem like the ipsec transport works.

Hello,

I managed to build IPSEC tunnels with AWS using IKEv2

Here are the IPSEC parameters :

VPN type : Static (route-based)
CGW model : ASA 5525-X OS 9.8

Phase 1: 
IKEv2 Encryption: AES-256  
IKEv2 Data integrity: SHA-256 
IKEv2 DH group: 14  
Lifetime: 28800 seconds   

Phase 2: 
IPSEC Encryption: AES-256  
IPSEC Data integrity: SHA-256 
IPSEC DH group: 14  
Lifetime: 3600 seconds   

Discussing with AWS support, it appears that only the first proposal will be used and must match AWS capabilities:

I believe that the same behavior is happening in case of IKEv2. If this is the case, I suspect if it is related to a known issue with AWS VPN Endpoint where AWS chooses the first proposal coming into the CGW device and if it does not support it, would not be able to bring UP the VPN. Hence, I would suggest you to make sure the first IKE proposal that CGW negotiates with, be the one that AWS supports.

In my case, the first proposal was AES-256/SHA512/DH21, second was AES-256/SHA256/DH14 and VPN would not go up. After specifying parameters below in the first proposal, VPN tunnels were up instantly.

Hope this helps.

Digging this back up, its been very helpful. Has anyone got this working with an IOS router instead of an ASA? I’m nearly there but am getting decaps and no encaps along with getting send errors. Can’t get it figured out.

Myself, I’ve been working with ASA5500s. Though if you manage to get your Fortigate working and can outlay what does it, I can probably fill in gaps.

What the ASA would need, as I see it (parentheticals are ‘known to work on an IKEv1’ on an ASA 55XX CGW I already have, and successfully passes traffic):

Encryption method (AES256)

Integrity hash (SHA, aka SHA1)

PRF hash (none because IKEv1 doesn’t use that but we’d need it for v2)

DH Group (2)

Pre-shared key (one key that works on both sides)

Hey, were you able to try this? I’m wondering if a new virtual private gateway is required to make this work. I don’t want to screw around too much with our production AWS. Maybe I’ll have to try this out with a personal account using my Meraki at home unless you’ve made progress.

Thank you. You saved me a call to tech support.

By the way, did you build a tunnel from scratch on both ends or were you able to migrate an existing tunnel by leaving the AWS side intact and updating the configs on the ASA?

FYI, I had to revert back to IKEv1 due to performance issues.

Hi again. I talked to AWS support today and they told me that they support route-based IKEv2 rather than policy-based.

Can you indicate what platform you are using and whether you used route-based or policy-based IPsec to make this work?

No luck getting it up and running with IKE v2. I tried with an existing VPG and new customer gateway and that didnt’ work (althought flipping it to IKE v1 made it work immediately, so I know the rest of the config is good).

I figured maybe the VPG also needs to be newly created since the announcement, so I deatched the existing VPG, created a new one and associated a new customer gateway and VPN connection to that, still the same, no luck.

I didn’t have any time to work with AWS support on it, but I’d love to know what the deal is.

Update: I just did everything from scratch and didn’t get any IKEv2 configs generated from Amazon for my device; didn’t try to do it anyway since I had no reason to think it would work.

It was a newly build IPSEC connection

Would you mind posting your scrubbed config as I don’t seem to be able to get mine to work at all on an ASA 5525 running 9.8(3)

As far as your performance issues. It may make a difference to use the following command. We have noticed issues with it and our ISR’s in the past. We would have random intermittent drops

set security-association lifetime kilobytes unlimited

For those interested, here is both a policy based and a route based/VTI IKEv2 ASA site-to-site configuration I was able to make work. If you are running ASA 9.7+ which supports VTI, do not use policy based for anything you care about uptime on. Period. You sacrifice multiple connection peers if you do it!

Policy based:

IKEv2 on ASA does not support multiple peers in a crypto map: see Cisco enhancement request CSCud22276, CDO login required. I believe this means that although a policy based IKEv2 VPN can be created, that you cannot leverage HA with multiple endpoints. I further believe (which I would see as understandable) that this is why AWS does not support policy based AWS Site-to-Site VPN on ASA.

# Your first ikev2 policy MUST be one that the AWS CGW will accept.
# Further, I believe it only attempts the first in each list item,
# if multiples are provided. E.g., 'group 5 2' will never work because
# CGW doesn't support phase 1 DH 5!
# x.x.x.x is your customer gateway endpoint IP address provided by AWS.
crypto ikev2 policy 1
 encryption aes-256
 integrity sha256
 group 14
 prf sha256
 lifetime seconds 28800  
object network AWS-VPC-SUBNET  
 subnet 172.31.0.0 255.255.0.0  
access-list outside_cryptomap_3 line 1 extended permit ip any object AWS-VPC-SUBNET   
group-policy GroupPolicy_x.x.x.x internal  
group-policy GroupPolicy_x.x.x.x attributes  
  vpn-tunnel-protocol ikev2
tunnel-group x.x.x.x type ipsec-l2l
tunnel-group x.x.x.x general-attributes
  default-group-policy GroupPolicy_x.x.x.x
tunnel-group x.x.x.x ipsec-attributes
  ikev2 local-authentication pre-shared-key YOUR-IKEV1-KEY-GOES-HERE
  ikev2 remote-authentication pre-shared-key YOUR-IKEV1-KEY-GOES-HERE
  isakmp keepalive threshold 10 retry 2
crypto ipsec ikev2 ipsec-proposal AWS-IKEV2
  protocol esp encryption aes-256
  protocol esp integrity sha-256
crypto map outside_map 4 match address outside_cryptomap_3
crypto map outside_map 4 set peer x.x.x.x
crypto map outside_map 4 set ikev2 ipsec-proposal AWS-IKEV2
crypto map outside_map 4 set pfs group14

Route/VTI based, this is the one to use:

Parts of this config provided by AWS when a VTI configuration is downloaded:

  • TUNNEL1-PEER
  • TUNNEL1-LOCALIP Typically a 169.x.x.x address in a /30 range.
  • TUNNEL1-REMOTEIP Typically a 169.x.x.x address in a /30 range.
  • TUNNEL1-PRESHAREDKEY This is the same as the IKEv1 key.
  • TUNNEL2-PEER
  • TUNNEL2-LOCALIP Typically a 169.x.x.x address in a /30 range.
  • TUNNEL2-REMOTEIP Typically a 169.x.x.x address in a /30 range.
  • TUNNEL2-PRESHAREDKEY This is the same as the IKEv1 key.

Parts of this config you must provide:

  • PROFILENAME (make it whatever you want, as long as it means something to you, so you can readily identify it in a configuration)
  • SUBNET The portion of the VPC (or the entire VPC range) you want to tunnel.
  • NETMASK The netmask of the subnet you want to tunnel.

config t
# The first ikev2 policy MUST be one that the AWS Site-to-Site VPN will accept.
# Further, I believe it only attempts the first in each list item,
# if multiples are provided. E.g., 'group 5 2' will never work because
# AWS Site-to-Site VPN doesn't support phase 1 DH 5!
crypto ikev2 policy 1
 encryption aes-256
 integrity sha256
 group 14
 prf sha256
 lifetime seconds 28800
exit

crypto ipsec ikev2 ipsec-proposal AWS-IKEV2
 protocol esp encryption aes-256
 protocol esp integrity sha-256
exit

crypto ipsec profile PROFILENAME
 set ikev2 ipsec-proposal AWS-IKEV2
 set pfs group14
 set security-association lifetime kilobytes unlimited
 set security-association lifetime seconds 3600
exit

tunnel-group TUNNEL1-PEER type ipsec-l2l
tunnel-group TUNNEL1-PEER ipsec-attributes
 ikev2 remote-authentication pre-shared-key TUNNEL1-PRESHAREDKEY
 ikev2 local-authentication pre-shared-key TUNNEL1-PRESHAREDKEY
 isakmp keepalive threshold 10 retry 10
exit

tunnel-group TUNNEL2-PEER type ipsec-l2l
tunnel-group TUNNEL2-PEER ipsec-attributes
 ikev2 remote-authentication pre-shared-key TUNNEL2-PRESHAREDKEY
 ikev2 local-authentication pre-shared-key TUNNEL2-PRESHAREDKEY
 isakmp keepalive threshold 10 retry 10
exit

interface Tunnel1
 nameif PROFILENAME-pri
 ip address TUNNEL1-LOCALIP 255.255.255.252
 tunnel source interface outside
 tunnel destination TUNNEL1-PEER
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile PROFILENAME
 no shutdown
exit

interface Tunnel2
 nameif PROFILENAME-sec
 ip address TUNNEL2-LOCALIP 255.255.255.252
 tunnel source interface outside
 tunnel destination TUNNEL2-PEER
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile PROFILENAME
 no shutdown
exit

route PROFILENAME-pri SUBNET NETMASK TUNNEL1-REMOTEIP 100
route PROFILENAME-sec SUBNET NETMASK TUNNEL2-REMOTEIP 200
end

Hi,

As indicated in my post, it is a route-based VPN

VPN type : Static (route-based)
CGW model : ASA 5525-X OS 9.8

I did not succeed building a policy-based IPSEC tunnel with IKEv2

I did end up testing it but no luck. Check my other comment further up a bit:

The fact the configs don’t generate with Ike v2 isn’t surprising. AWS says as much, that configurations would need to be manually update to reflect v2 in the interim.