IKEv2 and Flex VPN using Cisco IOS. Syntax and Logic
In this article, I tried to describe in the most accessible and concise manner what IKEv2 is, FlexVPN, and how it is implemented in Cisco IOS routers. For a better understanding of the content, it is necessary that the reader, at the time of familiarization with the text below, did not frighten words such as VPN, IPSec, ISAKMP, ISAKMP Profile, etc. In addition, it is advisable to have a good understanding of how different types of VPNs are configured using VTI interfaces (or GRE over IPSec) on Cisco equipment, since the article relies heavily on these issues.
Immediately you need to emphasize that you should not think that IKEv2 is something completely new, difficult to understand and completely changes the whole concept of building VPN networks. IKE (both 1 and 2) are intended only to provide ESP (well, or AH, if someone needs it) with the necessary key information needed by the specified protocols to directly protect data. ESP itself, its modes of operation (tunnel / transport) and all related concepts do not change.
I will list the most significant things in my opinion:
1. Both protocols work on UDP / 500 (4500 in the case of NAT-T), but are incompatible with each other, i.e. it does not work so that at one end of the tunnel was IKEv1, and at the other - IKEv2. In this case, the same router can terminate on itself and IKEv2 and IKEv1 tunnels simultaneously. There are enough differences in the IKEv1 and 2 headers so that the router can determine what it is dealing with, despite the same ports.
')
2. In IKEv2, there are no longer such concepts as aggressive / main mode, which is one of the aspects that make the protocol easier to understand.
3. In IKEv2, the term phase1 is replaced by IKE_SA_INIT (two message exchange, which ensures the negotiation of encryption / hashing protocols and the generation of DH keys), and phase 2 - by IKE_AUTH (also two messages that directly implement peer authentication and key generation for ESP). The data exchange in IKE_AUTH is always encrypted using SA, formed by IKE_SA_INIT. Isakmp SA is now called ikev2 sa, and ipsec sa is Child SA.
4. In IKEv2, the authentication method between peers is no longer automatically negotiated and is not tied to one or another IKEv2 policy. Those. if earlier in IKEv1 of each isakmp policy there was an authentication string, which indicated what type of authentication would be if this policy is chosen, then now the authentication method is set manually and it is clearly determined that with this peer will be certificate authentication, but with this is according to the pre-shared key. In addition, asymmetric authentication has become possible in IKEv2. Those. You can make Endpoint A authenticate Endpoint B with certificates, while B authenticate A with a pre-shared key. Or, A authenticates B with a pre-shared key1, while B authenticates A with a pre-shared key2. Other options are possible, incl. authentication using various EAP methods.
5. Mode Config (what was called phase 1.5 in ikev1 and is used to configure remote connections for RAVPN / EasyVPN), NAT-T and keepalives are now directly described in the protocol specification and are an integral part of it. Previously, these things were implemented by vendors in their own way as needed.
6. In IKEv2, an additional control-plane (services plane) protection mechanism against DoS attacks has been added. Its essence is that before responding to each request to establish a secure connection (IKE_SA_INIT) IKEv2 VPN gateway sends a cookie to the source of such request, and waits for it to respond the same. If the source responded - great, you can start generating DH with it. If the source does not respond (in the case of a DoS attack, this is what happens, this is essentially comparable to the TCP SYN flood attack), the VPN gateway just forgets about it. Without this mechanism, with each IKE_SA_INIT request from IKEv2 from anyone, the VPN gateway would try to generate the DH key (which, as we know, is a very expensive process) and would soon remain with the killed (albeit temporarily) control-plane.
FlexVPN is a framework implementing IKEv2 in Cisco IOS routers. Those. This is IKEv2 + IPSec in the IOS command syntax. No more.
The main feature, FlexVPN (Flex keyword - Flexible), which Cisco positions as a distinctive feature of FlexVPN, is that the same VPN gateway configuration allows different types of tunnels to be hooked to it - Remote Access, Site-to-Site, etc . Although, in my opinion, the same (or almost the same) flexibility can be achieved in the traditional IKEv1 configuration, if you use the VTI interfaces. Well, okay, this is all my IMHO.
Next, let us analyze now what the FlexVPN syntax looks like, what commands it uses, what they mean, what they are for, how they relate to similar commands in IKEv1.
So, the main (and, IMHO, all) components of IKEv2 in Cisco IOS are:
1. Proposal
2. Policy
3. Keyring
4. Profile
Next on each in order.
Posal
IKEv2 proposal limits which algorithms will be used to establish / protect the IKE_SA_INIT phase. In essence, this is an analogue of the crypto isakmp policy in IKEv1, although not fully.
Looks like that:
The first difference from the isakmp policy is that several algorithms / lengths of encryption keys / DH / hashes can be thrown into one proposal. The second difference mentioned earlier is that there is no authentication string, since now authentication is a separate issue. The third difference - the proposal is not an independent part of the config and should be placed in the policy.
Policy
IKEv2 Policy is the container for the proposal, and not only. Here is an example first, and then I will explain:
As you can see, policy refers to the proposal. But, besides this, it adds the ability to choose one or another proposal depending on the fact 1) in which VRF the interface to which the remote peer is connected is located; 2) to what local address the remote feast is connected. If we compare this to crypto isakmp policy in IKEv1, then there crypto isakmp policy was global for all connections. In principle, there was no possibility to make it so that for part of peers only policy 1,2,3 can be used and for another part 4.5.6. There is such an opportunity, although I am not sure that there is a great practical benefit to this. But nonetheless…
Thus, I emphasize once again:
The crypto ikev2 policy + crypto ikev2 proposal in IKEv2 performs the same role as the crypto isakmp policy in IKEv1.
Keyring
IKEv2 Keyring is a repository in which pre-shared keys are stored. Obviously, keyring is used and makes sense only if the pre-shared key authentication method is selected. In case PKI is used for authentication, you need to configure not a keyring, but a Trustpoint. If we draw an analogy with IKEv1, in the simplest case, the following construction was used to set the pre-shared keys:
Those. The pre-shared keys were separate configuration items, each on its own. In IKEv2, a kind of container appeared, the keyring, thanks to which the config looks more structured, + some additional features are added.
An example of how a keyring of a vpn gateway installed in HQ might look like to interact with two remote sites (in the absence of deep skills in drawing tables in html, inserted as an image):
Profile
IKEv2 profile is the basis of FlexVPN and is its main component. It defines the “policy” of remote access to the VPN gateway. According to its purpose, IKEv2 profile is completely analogous to IKEv1 isakmp profile in Cisco IOS or the tunnel-group (connection profile) if you remember the ASA, but it has more features and is more flexible in configuration. This is a kind of repository of parameters that are not automatically agreed by the participants of the VPN interaction, but are determined statically. What functions does it perform? During the installation of the VPN connection, and in particular the IKE_INIT_SA VPN gateway, you need to know (the numbers in brackets are not links to the list of references, but links to the config lines below):
1. How to authenticate a connecting peer (PKI? Pre-shared keys?). In IKEv2, the authentication type, as I mentioned earlier, is not negotiated, and must be explicitly defined. FlexVPN uses ikev2 profile (1) for this.
2. What should be the parameters of dead-peer detection (DPD). In IKEv2, DPD timers are also not negotiated automatically, but are set manually in the settings of ikev2 profile (2) (although they can be defined globally).
3. Which keyring should be used to authenticate a remote peer in the case of pre-shared key authentication is also an ikev2 profile (3) parameter.
4. Which trustpoint to use to authenticate a remote peer, in the case of PKI authentication, is also an ikev2 profile (4) parameter.
5. How to present yourself to a remote peer, what to choose as your own IKEv2_ID is also an option to ikev2 profile (5) .
6. In which iVRF - put traffic, after it is decrypted (VRF-aware IPSec) - ikev2 profile (6) parameter.
Example IKEv2 profile:
crypto ikev2 profile profile_name
match local_address | certificate map | FVRF | IKEv2_ID of remote peer
authentication {local | remote {rsa-sig | pre-share | ecdsa-sig}} (1)
dpd interval retry-interval {on-demand | periodic} (2)
identity local {address | dn | email | fqdn | key-id} (5)
keyring name (3)
ivrf name (6)
pki trustpoint label [sign | verify] (4)
virtual-template number
Those. The IKEv2 profile defines many parameters for a VPN connection. And there can be many such profiles in the configuration, and each one can define a different set of parameters, depending on who / what connects to the gateway (or to whom the gateway connects). And this “depending” is determined by the match directive (there can be several match directives in one profile).
For example, we have two profiles:
With this setting, when a remote peer with Src IP = 1.1.1.1 connects to the local gateway, the parameters described in PROFILE1 will be applied to it (peer). When a peer is connected to the local gateway with fqdn = remotepeer2.someorg.com, the parameters described in PROFILE2 will be applied to it.
Here it is necessary to draw an invisible line. It is necessary to say that at this point everything that is called IKEv2 in the context of setting up a protocol using IOS means is over and nothing more will come of it. And, you can make the line visible. Here she is:
So, these four constructions shown above (policy, proposal, keyring, profile) define the configuration of what was called phase1 in IKEv1. In IKEv2, this is IKE_SA_INIT, but the essence is absolutely the same.
What to do after IKE_SA_INIT is configured? Right. You need to configure the IPSec profile, determine which traffic will go through the tunnel (proxy-ACL or tunnel interface - VTI, where routing is responsible for this), i.e. do what IKEv1 called the second phase settings. This part of the settings in IKEv1 and IKEv2 is absolutely identical. How the config looks like in its entirety, let me give you a simple example below.
It is necessary to mention that FlexVPN in IOS by default is pre-configured so that it requires a minimum of actions from the administrator to quickly configure the VPN, if the administrator does not really want / too lazy to understand how it all works and perform some clever settings. For this are the so-called smart-defaults. Smart-defaults are pre-configured default ikev2 proposal / policy / profile, ipsec profile, etc. Objectively, smart-defaults can be very useful and have a right to exist. Why constantly drive in the same settings if they are already in the config? You can view them by running the sh run all | s crypto. The output of the command will be something like this (part of the output is omitted as unnecessary):
Those. you can see that in the default configuration, both the IKEv2 proposal and the IKEv2 policy, and the IPSec transform-set and the IPSec profile are configured. Moreover, they are configured so that the most serious algorithms have the highest priority, which suits us perfectly. Naturally, the maximum predictability of the VPN operation will be provided only by manual configuration of all parameters, but as the last-resort, the default ones can be used.
Next, we consider a fairly simple example of a Site-to-Site VPN with pre-shared authentication. The topology looks like this:
You need to configure an IPSec / IKEv2 tunnel between the routers Site1Router and Site2Router and ensure that the loopbacks of each of the routers through the tunnel are mutually accessible using a dynamic routing protocol.
The configuration of each router in this case will be as follows:
In this example, the config that is related to the IKEv2 configuration and IPSec is highlighted. The example uses the very smart-defaults (see the sh run all output above — that is, you can simply draw and mentally draw these settings to the configuration of each router), which set the default parameters for IKEv2 policy / proposal, IPSec transform-set . IPSec profile is also used by default. In the config, it refers to the ikev2 profile and hangs on the tunnel interface to protect it. As a result, the configuration is quite compact and easy to read. As you can see from the example, the configuration of everything in IKEv1 related to phase 2 is similar to that in IKEv1. Those. the same crypto ipsec transform set is created (the default is taken here), this transform-set together with the ikev2 profile is bound to the ipsec profile, the ipsec profile is hung on the interface running in the ipsec ipv4 (VTI) mode.
After the tunnel is successfully established, let's see the output of some commands:
Site1Router # sh crypto ipsec sa
The output of sh crypto ipsec sa is the same as if we were setting up traditional Ikev1, because ESP doesn't care who prepares key information for it - IKEv2 or IKEv1. Further:
Site1Router # sh crypto ikev2 sa detailed
Here we are already seeing information specific to IKEv2 - the encryption / hashing algorithms / DH groups used. It is also seen that the IKEv2 profile was not tied to a specific VRF (since smart-default was used). It can be seen that the initiator of the connection was Site2Router.
Further:
Site1Router # sh crypto engine connections active
Here again, nothing new. We have two unidirectional IPSec SA (lines starting with 11 and 12) and one bidirectional IKEv2 SA.
The output of sh crypto isakmp sa, as expected, shows nothing:
Site1Router # sh crypto isakmp sa
Somehow like this. I hope all this text has not turned out to be too confusing or too superficial, and will be useful to someone.
Foreword
Immediately you need to emphasize that you should not think that IKEv2 is something completely new, difficult to understand and completely changes the whole concept of building VPN networks. IKE (both 1 and 2) are intended only to provide ESP (well, or AH, if someone needs it) with the necessary key information needed by the specified protocols to directly protect data. ESP itself, its modes of operation (tunnel / transport) and all related concepts do not change.
Briefly about the main features and differences of IKEv2 from its predecessor
I will list the most significant things in my opinion:
1. Both protocols work on UDP / 500 (4500 in the case of NAT-T), but are incompatible with each other, i.e. it does not work so that at one end of the tunnel was IKEv1, and at the other - IKEv2. In this case, the same router can terminate on itself and IKEv2 and IKEv1 tunnels simultaneously. There are enough differences in the IKEv1 and 2 headers so that the router can determine what it is dealing with, despite the same ports.
')
2. In IKEv2, there are no longer such concepts as aggressive / main mode, which is one of the aspects that make the protocol easier to understand.
3. In IKEv2, the term phase1 is replaced by IKE_SA_INIT (two message exchange, which ensures the negotiation of encryption / hashing protocols and the generation of DH keys), and phase 2 - by IKE_AUTH (also two messages that directly implement peer authentication and key generation for ESP). The data exchange in IKE_AUTH is always encrypted using SA, formed by IKE_SA_INIT. Isakmp SA is now called ikev2 sa, and ipsec sa is Child SA.
4. In IKEv2, the authentication method between peers is no longer automatically negotiated and is not tied to one or another IKEv2 policy. Those. if earlier in IKEv1 of each isakmp policy there was an authentication string, which indicated what type of authentication would be if this policy is chosen, then now the authentication method is set manually and it is clearly determined that with this peer will be certificate authentication, but with this is according to the pre-shared key. In addition, asymmetric authentication has become possible in IKEv2. Those. You can make Endpoint A authenticate Endpoint B with certificates, while B authenticate A with a pre-shared key. Or, A authenticates B with a pre-shared key1, while B authenticates A with a pre-shared key2. Other options are possible, incl. authentication using various EAP methods.
5. Mode Config (what was called phase 1.5 in ikev1 and is used to configure remote connections for RAVPN / EasyVPN), NAT-T and keepalives are now directly described in the protocol specification and are an integral part of it. Previously, these things were implemented by vendors in their own way as needed.
6. In IKEv2, an additional control-plane (services plane) protection mechanism against DoS attacks has been added. Its essence is that before responding to each request to establish a secure connection (IKE_SA_INIT) IKEv2 VPN gateway sends a cookie to the source of such request, and waits for it to respond the same. If the source responded - great, you can start generating DH with it. If the source does not respond (in the case of a DoS attack, this is what happens, this is essentially comparable to the TCP SYN flood attack), the VPN gateway just forgets about it. Without this mechanism, with each IKE_SA_INIT request from IKEv2 from anyone, the VPN gateway would try to generate the DH key (which, as we know, is a very expensive process) and would soon remain with the killed (albeit temporarily) control-plane.
What is FlexVPN?
FlexVPN is a framework implementing IKEv2 in Cisco IOS routers. Those. This is IKEv2 + IPSec in the IOS command syntax. No more.
The main feature, FlexVPN (Flex keyword - Flexible), which Cisco positions as a distinctive feature of FlexVPN, is that the same VPN gateway configuration allows different types of tunnels to be hooked to it - Remote Access, Site-to-Site, etc . Although, in my opinion, the same (or almost the same) flexibility can be achieved in the traditional IKEv1 configuration, if you use the VTI interfaces. Well, okay, this is all my IMHO.
Next, let us analyze now what the FlexVPN syntax looks like, what commands it uses, what they mean, what they are for, how they relate to similar commands in IKEv1.
FlexVPN syntax for IKEv2 configuration
So, the main (and, IMHO, all) components of IKEv2 in Cisco IOS are:
1. Proposal
2. Policy
3. Keyring
4. Profile
Next on each in order.
Posal
IKEv2 proposal limits which algorithms will be used to establish / protect the IKE_SA_INIT phase. In essence, this is an analogue of the crypto isakmp policy in IKEv1, although not fully.
Looks like that:
crypto ikev2 proposal PROP_1 encryption aes-cbc-256 aes-cbc-128 3des group 14 5 2 integrity sha 256 sha1 md5
The first difference from the isakmp policy is that several algorithms / lengths of encryption keys / DH / hashes can be thrown into one proposal. The second difference mentioned earlier is that there is no authentication string, since now authentication is a separate issue. The third difference - the proposal is not an independent part of the config and should be placed in the policy.
Policy
IKEv2 Policy is the container for the proposal, and not only. Here is an example first, and then I will explain:
crypto ikev2 policy POLICY_1 match vrf VRF1 match address local 203.0.113.10 proposal PROP_1
As you can see, policy refers to the proposal. But, besides this, it adds the ability to choose one or another proposal depending on the fact 1) in which VRF the interface to which the remote peer is connected is located; 2) to what local address the remote feast is connected. If we compare this to crypto isakmp policy in IKEv1, then there crypto isakmp policy was global for all connections. In principle, there was no possibility to make it so that for part of peers only policy 1,2,3 can be used and for another part 4.5.6. There is such an opportunity, although I am not sure that there is a great practical benefit to this. But nonetheless…
Thus, I emphasize once again:
The crypto ikev2 policy + crypto ikev2 proposal in IKEv2 performs the same role as the crypto isakmp policy in IKEv1.
Keyring
IKEv2 Keyring is a repository in which pre-shared keys are stored. Obviously, keyring is used and makes sense only if the pre-shared key authentication method is selected. In case PKI is used for authentication, you need to configure not a keyring, but a Trustpoint. If we draw an analogy with IKEv1, in the simplest case, the following construction was used to set the pre-shared keys:
crypto isakmp key cisco address xxxx 255.255.255.0
Those. The pre-shared keys were separate configuration items, each on its own. In IKEv2, a kind of container appeared, the keyring, thanks to which the config looks more structured, + some additional features are added.
An example of how a keyring of a vpn gateway installed in HQ might look like to interact with two remote sites (in the absence of deep skills in drawing tables in html, inserted as an image):
Profile
IKEv2 profile is the basis of FlexVPN and is its main component. It defines the “policy” of remote access to the VPN gateway. According to its purpose, IKEv2 profile is completely analogous to IKEv1 isakmp profile in Cisco IOS or the tunnel-group (connection profile) if you remember the ASA, but it has more features and is more flexible in configuration. This is a kind of repository of parameters that are not automatically agreed by the participants of the VPN interaction, but are determined statically. What functions does it perform? During the installation of the VPN connection, and in particular the IKE_INIT_SA VPN gateway, you need to know (the numbers in brackets are not links to the list of references, but links to the config lines below):
1. How to authenticate a connecting peer (PKI? Pre-shared keys?). In IKEv2, the authentication type, as I mentioned earlier, is not negotiated, and must be explicitly defined. FlexVPN uses ikev2 profile (1) for this.
2. What should be the parameters of dead-peer detection (DPD). In IKEv2, DPD timers are also not negotiated automatically, but are set manually in the settings of ikev2 profile (2) (although they can be defined globally).
3. Which keyring should be used to authenticate a remote peer in the case of pre-shared key authentication is also an ikev2 profile (3) parameter.
4. Which trustpoint to use to authenticate a remote peer, in the case of PKI authentication, is also an ikev2 profile (4) parameter.
5. How to present yourself to a remote peer, what to choose as your own IKEv2_ID is also an option to ikev2 profile (5) .
6. In which iVRF - put traffic, after it is decrypted (VRF-aware IPSec) - ikev2 profile (6) parameter.
Example IKEv2 profile:
crypto ikev2 profile profile_name
match local_address | certificate map | FVRF | IKEv2_ID of remote peer
authentication {local | remote {rsa-sig | pre-share | ecdsa-sig}} (1)
dpd interval retry-interval {on-demand | periodic} (2)
identity local {address | dn | email | fqdn | key-id} (5)
keyring name (3)
ivrf name (6)
pki trustpoint label [sign | verify] (4)
virtual-template number
Those. The IKEv2 profile defines many parameters for a VPN connection. And there can be many such profiles in the configuration, and each one can define a different set of parameters, depending on who / what connects to the gateway (or to whom the gateway connects). And this “depending” is determined by the match directive (there can be several match directives in one profile).
For example, we have two profiles:
crypto ikev2 profile PROFILE1 match identity remote address 1.1.1.1 followed by the PROFILE1 profile parameter set crypto ikev2 profile PROFILE2 match identity remote fqdn remotepeer2.someorg.com followed by a set of PROFILE2 profile parameters
With this setting, when a remote peer with Src IP = 1.1.1.1 connects to the local gateway, the parameters described in PROFILE1 will be applied to it (peer). When a peer is connected to the local gateway with fqdn = remotepeer2.someorg.com, the parameters described in PROFILE2 will be applied to it.
Here it is necessary to draw an invisible line. It is necessary to say that at this point everything that is called IKEv2 in the context of setting up a protocol using IOS means is over and nothing more will come of it. And, you can make the line visible. Here she is:
What's next?
So, these four constructions shown above (policy, proposal, keyring, profile) define the configuration of what was called phase1 in IKEv1. In IKEv2, this is IKE_SA_INIT, but the essence is absolutely the same.
What to do after IKE_SA_INIT is configured? Right. You need to configure the IPSec profile, determine which traffic will go through the tunnel (proxy-ACL or tunnel interface - VTI, where routing is responsible for this), i.e. do what IKEv1 called the second phase settings. This part of the settings in IKEv1 and IKEv2 is absolutely identical. How the config looks like in its entirety, let me give you a simple example below.
To not think at all
It is necessary to mention that FlexVPN in IOS by default is pre-configured so that it requires a minimum of actions from the administrator to quickly configure the VPN, if the administrator does not really want / too lazy to understand how it all works and perform some clever settings. For this are the so-called smart-defaults. Smart-defaults are pre-configured default ikev2 proposal / policy / profile, ipsec profile, etc. Objectively, smart-defaults can be very useful and have a right to exist. Why constantly drive in the same settings if they are already in the config? You can view them by running the sh run all | s crypto. The output of the command will be something like this (part of the output is omitted as unnecessary):
crypto ikev2 proposal default encryption aes-cbc-256 aes-cbc-192 aes-cbc-128 integrity sha512 sha384 sha256 sha1 md5 group 5 2 crypto ikev2 policy default matchfvrf any proposal default crypto ikev2 natkeepalive 0 crypto ikev2 diagnose error 50 crypto ikev2 dpd 0 0 periodic crypto ikev2 limit max-in-negotation-sa 40 crypto ikev2 limit max-sa 0 crypto ikev2 window 5 crypto ikev2 fragmentation mtu 576 crypto ipsec transform-set default esp-aes esp-sha-hmac mode transport crypto ipsec profile default set security-association lifetime kilobytes 4608000 set security-association lifetime seconds 3600 no set security-association idle-time no set security-association replay window-size
Those. you can see that in the default configuration, both the IKEv2 proposal and the IKEv2 policy, and the IPSec transform-set and the IPSec profile are configured. Moreover, they are configured so that the most serious algorithms have the highest priority, which suits us perfectly. Naturally, the maximum predictability of the VPN operation will be provided only by manual configuration of all parameters, but as the last-resort, the default ones can be used.
Example
Next, we consider a fairly simple example of a Site-to-Site VPN with pre-shared authentication. The topology looks like this:
You need to configure an IPSec / IKEv2 tunnel between the routers Site1Router and Site2Router and ensure that the loopbacks of each of the routers through the tunnel are mutually accessible using a dynamic routing protocol.
The configuration of each router in this case will be as follows:
In this example, the config that is related to the IKEv2 configuration and IPSec is highlighted. The example uses the very smart-defaults (see the sh run all output above — that is, you can simply draw and mentally draw these settings to the configuration of each router), which set the default parameters for IKEv2 policy / proposal, IPSec transform-set . IPSec profile is also used by default. In the config, it refers to the ikev2 profile and hangs on the tunnel interface to protect it. As a result, the configuration is quite compact and easy to read. As you can see from the example, the configuration of everything in IKEv1 related to phase 2 is similar to that in IKEv1. Those. the same crypto ipsec transform set is created (the default is taken here), this transform-set together with the ikev2 profile is bound to the ipsec profile, the ipsec profile is hung on the interface running in the ipsec ipv4 (VTI) mode.
Some show commands
After the tunnel is successfully established, let's see the output of some commands:
Site1Router # sh crypto ipsec sa
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 10.1.12.1
protected vrf: (none)
local ident (addr / mask / prot / port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr / mask / prot / port): (0.0.0.0/0.0.0.0/0/0)
current_peer 10.1.23.3 port 500
PERMIT, flags = {origin_is_acl,}
#pkts encaps: 1680, #pkts encrypt: 1680, #pkts digest: 1680
#pkts decaps: 1678, #pkts decrypt: 1678, #pkts verify: 1678
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt .: 10.1.12.1, remote crypto endpt .: 10.1.23.3
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1 / 0
current outbound spi: 0x31A6B95A (833010010)
PFS (Y / N): N, DH group: none
inbound esp sas:
spi: 0xE6E9033F (3874030399)
transform: esp-aes esp-sha-hmac,
in use settings = {Tunnel,}
conn id: 11, flow_id: 11, sibling_flags 80000040, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k / sec): (4268866/1723)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE (ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x31A6B95A (833010010)
transform: esp-aes esp-sha-hmac,
in use settings = {Tunnel,}
conn id: 12, flow_id: 12, sibling_flags 80000040, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k / sec): (4268866/1723)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE (ACTIVE)
The output of sh crypto ipsec sa is the same as if we were setting up traditional Ikev1, because ESP doesn't care who prepares key information for it - IKEv2 or IKEv1. Further:
Site1Router # sh crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf / ivrf Status
1 10.1.12.1/500 10.1.23.3/500 none / none READY
Encr: AES-CBC, keysize: 256, Hash: SHA512, DH Grp: 5, Auth sign: PSK, Auth verify: PSK
Life / Active Time: 86400/12375 sec
CE id: 1003, Session-id: 2
Status Description: Negotiation done
Local spi: 1625F2D9751CC54F Remote spi: B9C9990767BC0006
Local id: 10.1.12.1
Remote id: 10.1.23.3
Local req msg id: 2 Remote req msg id: 6
Local next msg id: 2 Remote next msg id: 6
Local req queued: 2 Remote req queued: 6
Local window: 5 Remote window: 5
DPD configured for 0 seconds, retry 0
NAT-T is not detected
Cisco Trust Security SGT is disabled
Initiator of SA: No
Here we are already seeing information specific to IKEv2 - the encryption / hashing algorithms / DH groups used. It is also seen that the IKEv2 profile was not tied to a specific VRF (since smart-default was used). It can be seen that the initiator of the connection was Site2Router.
Further:
Site1Router # sh crypto engine connections active
Crypto Engine Connections
ID Type Algorithm Encrypt Decrypt LastSeqN IP Address
11 IPsec AES + SHA 0 223 223 10.1.12.1
12 IPsec AES + SHA 222 0 0 10.1.12.1
1003 IKEv2 SHA512 + AES256 0 0 0 10.1.12.1
Here again, nothing new. We have two unidirectional IPSec SA (lines starting with 11 and 12) and one bidirectional IKEv2 SA.
The output of sh crypto isakmp sa, as expected, shows nothing:
Site1Router # sh crypto isakmp sa
IPv4 Crypto ISAKMP SA dst src state conn-id status
Somehow like this. I hope all this text has not turned out to be too confusing or too superficial, and will be useful to someone.
Source: https://habr.com/ru/post/186126/
All Articles