…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?
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
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 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.
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)
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.
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?
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.
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 requestCSCud22276, 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
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.
