Summary
This document outlines the configurations necessary to build an IPsec tunnel with IKEv2 between a Cisco ASA and a Juniper SSG. I found a fair amount of documentation on the web that used IKEv1, but IKEv2 between the two types of devices was not well documented. It wasn't too difficult to make the leap from IKEv1 to IKEv2, however there were some lessons learned along the way that I'll pass along here.
The goal of this exercise was to protect the information traversing the tunnel at the highest level possible (for both encryption and integrity) without regard to CPU or memory overhead. However, as you'll see as you read this document, there were a couple of gotcha moments that were traced back to specific software versions causing issues. In one unresolved issue, I was unable to use SHA2 with a 256 bit digest. This will require further investigation and potentially a software upgrade or a call into TAC/JTAC.
The goal of this exercise was to protect the information traversing the tunnel at the highest level possible (for both encryption and integrity) without regard to CPU or memory overhead. However, as you'll see as you read this document, there were a couple of gotcha moments that were traced back to specific software versions causing issues. In one unresolved issue, I was unable to use SHA2 with a 256 bit digest. This will require further investigation and potentially a software upgrade or a call into TAC/JTAC.
The configuration snippets I show here are for a single tunnel between the Cisco and Juniper devices and use pre-shared keys. Here's a topology drawing of the setup.
Onto the configs...
Cisco ASA
The hardware and software used in this prototype was a Cisco ASA 5505 running ASA Software Version 8.4.4(1).
IKEv2 Policy
The first step on the ASA is to define the IKEv2 policy. This policy must match the Juniper's settings. The IKEv2 policy defines the IKE_SA_INIT proposal information. In IKEv1 terminology, this was known as phase 1. IKE_SA_INIT is the initial exchange in which the peers establish a secure channel. After IKE_SA_INIT completes the initial exchange, all further exchanges are encrypted.
crypto ikev2 policy 1
integrity sha
encryption aes-256
prf sha
group 5
lifetime seconds 86400
*Potential Bug Alert*
If you notice, the integrity keyword was sha, not sha256. This is because at these two code versions of the ASA and Juniper, IKEv2 would not establish a security association when SHA2 with a 256 bit digest was used (which is what the sha256 keyword specifies). Keep this in mind when specifying your IKEv2 parameters. This issue corresponds to a similar IKEv2 problem with encryption explained in the Juniper configuration section. That bug is fixed with an upgrade to the Juniper code.
Crypto ACL and Interface Specification
You must define an access list that instructs the ASA to encrypt traffic originating from behind the ASA and destined for the LAN2 segment.
The source in this ACL is the LAN1 subnet behind the ASA. The destination in this ACL is the LAN2 subnet behind the Juniper. The LAN2 subnet is the network that the hosts on the LAN1 subnet want to access via the IPSec tunnel.
The crypto ACL on the Juniper should be a mirror image of this ACL (see the section on proxy-id). That means that the source and destination addresses are reversed on the crypto ACL on the Juniper. This allows return traffic from the Juniper to be sourced on the LAN2 subnet and travel back through the IPSec tunnel.
access-list ACL-IKEV2-CRYPTO extended permit ip 192.168.30.0 255.255.255.0 192.168.10.0 255.255.255.0
You must enable IKEv2 on the interface you plan to use it on.
crypto ikev2 enable outside
IPsec Proposal
The ipsec-proposal keyword specifies the name of the proposal you are building and contains the integrity and encryption levels you'd like the ESP protocol to use within your tunnel. These settings must match with the Juniper.
The negotiation of these parameters previously took place during an exchange that was known as phase 2 in IKEv1 terminology. However, in IKEv2 the entire key exchange process was overhauled, and this negotiation is known as the IKE_AUTH exchange.
crypto ipsec ikev2 ipsec-proposal IPSEC_PROPOSAL
protocol esp encryption aes-256
protocol esp integrity sha-1
Tunnel Group
The tunnel-group or connection policy is a set of attributes that define the parameters by which a group of users (or in this case simply just the Juniper SSG) may access or use the VPN. Generally speaking, most of the tunnel-group commands are needed on remote access VPNs, not site-to-site VPNs.
However, the key attribute defined within the tunnel-group for an IKEv2 VPN are the pre-shared keys. Theoretically you could have different pre-shared keys on each end of the tunnel. However you'll see on the Juniper that it doesn't appear to support that. As such, I made the remote and local pre-shared key the same on the ASA.
tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 ipsec-attributes
ikev2 remote-authentication pre-shared-key cisco123
ikev2 local-authentication pre-shared-key cisco123
Crypto Map
The crypto map is the method in which you pull together various elements of the IPsec security association parameters. This includes:
1) What traffic you wish to protect (the ACL you created previously).
2) The peer that you should build the IPsec security association to
3) What type of IKEv2 proposal should be used.
If you were using IKEv1, this would be called a transform-set, but with IKEv2 it is called a proposal. This proposal defines the integrity and encryption of the IPsec security association.
Nothing stops you from specifying both IKEv1 transform sets and IKEv2 proposals and let the negotiation process decide which to use. However in the interest of guaranteeing IKEv2 be used for this write-up, only an IKEv2 proposal is specified.
Note: You can only apply one crypto map to each interface on an ASA. To build multiple IPsec SA's, you will need to specify different crypto map entries. Entries are identified (and ranked) by their sequence number. The higher the number the sooner it is checked to see if the traffic matches that crypto map during packet processing. In this example, the sequence number for the tunnel is 20.
crypto map MAP-JUNIPER 20 match address ACL-IKEV2-CRYPTO
crypto map MAP-JUNIPER 20 set peer 50.79.210.1
crypto map MAP-JUNIPER 20 set ikev2 ipsec-proposal IPSEC_PROPOSAL
crypto map MAP-JUNIPER interface outside
That does it for the ASA config. Next up is the Juniper.
Juniper SSG
The hardware and software used in this prototype was a Juniper SSG 5 running 6.3.0r14.0.
Interface Specification
In order to build a tunnel on a SSG, you must define the interface you want to use. The logical interface is created as type tunnel and in this example it is the first tunnel (.1). The tunnel interface is attached to the externally facing physical interface in the untrust zone.
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet0/0
Proposal Information
Even when using IKEv2, Juniper still uses phase 1 and phase 2 nomenclature in their proposal definitions. This can be confusing when matching parameters between the two devices.
The phase 1 Juniper proposal must match the IKEv2 policy defined on the ASA. The SSG does not specify IKEv2 in this configuration line. Instead, it sets the attributes for IKE and uses the keyword p1-proposal for phase 1. These attributes are compatible with either IKEv1 or IKEv2.
set ike p1-proposal PHASE1_PROPOSAL preshare group5 esp aes256 sha-1 seconds 86400
*Potential Bug Alert*
When aes256 is configured in the p1-proposal and the Juniper is running 6.2.0r7.0, the IKEv2 security association fails to establish. The debugs are not helpful and as such I am not posting them here. The fix was to upgrade to 6.3.0r14.0 on the Juniper. It resolved the problem with encryption and allowed the IKEv2 security association to build.
Define the IKE Gateway
Using the phase 1 proposal defined above, configure the IKEv2 peer. This configuration line actually defines the parameters for IKEv2 used between the two VPN peers. It uses the set of valid attributes defined in the PHASE1_PROPOSAL attribute set. The name ASA is simply a common identifier string for the VPN peer. The address parameter is the IP address of the VPN peer, in this case the Cisco ASA.
set ike gateway ikev2 ASA address 1.1.1.1 preshare cisco123 proposal PHASE1_PROPOSAL
Define IPsec Proposal Information
In Juniper terminology (and similar to IKEv1) IKE phase 2 sets the parameters for the securing the data transferred inside the IPsec tunnel. This configuration on the Juniper must match the configuration of the IKEv2 IPsec proposal on the ASA. It was defined as IPSEC-PROPOSAL on the ASA config. The addition of no-pfd is very important. No perfect forward secrecy is implied on the ASA's and is not an explicit configuration item on the ASA. However, it must be configured here.
set ike p2-proposal PHASE2_PROPOSAL no-pfs esp aes256 sha-1 second 3600
Build the VPN
The following section is roughly equivalent to the ASA crypto map.
The set vpn configuration parameters specify the following:
1) The vpn name is a string value. In this example, I used the IP address of the VPN peer as the name of the VPN (1.1.1.1).
2) The IKE gateway that was discussed previously, (which I named ASA), must be specified here so that the IKEv2 security association is used to negotiate the rest of the IKEv2 parameters.
set vpn 1.1.1.1 gateway ASA proposal PHASE2_PROPOSAL
The following is equivalent to the ASA command that binds its crypto map to an interface.
set vpn 1.1.1.1 id 1 bind interface tunnel.1
The proxy-id command identifies the traffic that is permitted over the tunnel. When the VPN peer is a Cisco device like in this case, the proxy-id must be configured as a mirror image of the crypto ACL on the ASA.
set vpn 1.1.1.1 proxy-id local-ip 192.168.10.0 255.255.255.0 remote-ip 192.168.30.0 255.255.255.0 ANY
Routing and Firewall Policies
Route all traffic to the LAN1 subnet behind the ASA via the tunnel interface on the SSG.
set vrouter trust-vr route 192.168.30.0/24 interface Tunnel.1
To allow the traffic via firewall policy:
First, define two address book entries for the subnets. The subnet behind the ASA is in the untrust zone. The subnet behind the SSG is in the Trust zone.
set address Trust "192.168.10.0/24" 192.168.10.0/24
set address Untrust "192.168.30.0/24" 192.168.30.0/24
Second, create two firewall policies that allow traffic in both directions.
set policy top from Untrust to Trust 192.168.30.0/24 192.168.10.0/24 any permit log
set policy top from Trust to Untrust 192.168.10.0/24 192.168.30.0/24 any permit log
That should do it from the Juniper side.
Consolidated Configuration
Cisco ASA (IKEv2 specifics only)
The IKEv2 policy
crypto ikev2 policy 1
encryption aes-256
integrity sha
group 5
prf sha
lifetime seconds 86400
The IKEv2 IPsec proposal
crypto ipsec ikev2 ipsec-proposal IPSEC_PROPOSAL
protocol esp encryption aes-256
protocol esp integrity sha-1
The crypto map configuration
crypto map MAP-JUNIPER 20 match address ACL-IKEV2-CRYPTO
crypto map MAP-JUNIPER 20 set peer 2.2.2.2
crypto map MAP-JUNIPER 20 set ikev2 ipsec-proposal IPSEC_PROPOSAL
crypto map MAP-JUNIPER interface outside
Enable IKEv2 on the correct interface
crypto ikev2 enable outside
Tunnel group for setting the pre-shared key
tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 ipsec-attributes
ikev2 remote-authentication pre-shared-key cisco123
ikev2 local-authentication pre-shared-key cisco123
Juniper SSG (IKEv2 specifics only)
set ike p1-proposal "PHASE1_PROPOSAL" preshare group5 esp aes256 sha-1 second 86400
set ike p2-proposal "PHASE2_PROPOSAL" no-pfs esp aes256 sha-1 second 3600
set ike gateway ikev2 "ASA" address 1.1.1.1 outgoing-interface "ethernet0/0" preshare "cisco123" proposal "PHASE1_PROPOSAL"
set vpn "1.1.1.1" gateway "ASA" replay tunnel idletime 0 proposal "PHASE2_PROPOSAL"
set vpn "1.1.1.1" id 0x1 bind interface tunnel.1
set vpn "1.1.1.1" proxy-id local-ip 192.168.10.0/24 remote-ip 192.168.30.0/24 "ANY"
Multiple IPsec Proposals
This support forum document states that the Cisco device should only be configured to send a single IPsec proposal for a static crypto map that is configured to a Juniper SSG peer. The following configuration line specifies the IPsec proposal. There is only one proposal, and as such, the bug does not appear affect the configuration as tested.
crypto map MAP-JUNIPER 20 set ikev2 ipsec-proposal IPSEC_PROPOSAL
From the Cisco ASA Configuration guide:
For IKEv2 proposals, you can configure multiple encryption and authentication types and multiple integrity algorithms for a single proposal. The ASA orders the settings from the most secure to the least secure and negotiates with the peer using that order. This allows you to potentially send a single proposal to convey all the allowed combinations instead of the need to send each allowed combination individually as with IKEv1.
It is unknown (and not tested) whether multiple encryption and authentication types in a single proposal would be affected by this bug.
Troubleshooting
On the Juniper:
get sa
get ike gateway
get event
On the Cisco ASA:
show crypto ikev2 sa
show crypto ipsec sa
clear ikev2 session
