Ever noticed when you issue a show running-config on a ASA to look up the VPN tunnel pre shared key and it appears as a “.”? Well here’s how to find out what the key is! More system:running-config. This will display the running-config with the pre shared key exposed. How to generate secure pre-shared keys (PSK) for an IPSec VPN I build VPNs regularly, and one of the problems that comes up regularly is how to exchange PSK's. Some people are happy to exchange them over email, and others not (particularly because of ISO/IEC 27002). Cisco Asa 5505 Activation Key Generator DOWNLOAD (Mirror #1).

IFM supplies network engineering services for $NZ180+GST per hour. If you require assistance with designing or engineering a Cisco network - hire us!

Note: This page uses client side Javascript. It does not transmit any information entered to IFM.

You are building a site to site VPN and need to exchange the PSK. However you are not allowed to email it, and TXTing never works as it mangles the PSK. What to do?

This tool uses client side javascript - so no information is ever transmitted - and generates a random PSK in your own web browser that rolls every 24 hours. All it requires is for both parties to have their machine clocks approximately correctly (so both machines calculate the same PSK).

Optionally, to make a more variable key, you can enter two encoding keys, and these keys must be exchanged between both parties. For example, you can make the two keys the public IP address of the two VPN terminators. Or you can use serial numbers, MAC addresses, or you could call each other and exchange two colours, favourite sports teams, etc. Note that whatever one party enters as 'Key 1' the other party must enter as 'Key 1', and whatever one party enters as 'Key 2' the other party must also enter as 'Key 2'.

Then the tool will take your two keys, add a unique salt for that 24 hour period, and generate a nasty PSK that no person would ever guess - and that has never been transmitted over any medium, ever.

This page uses Javascript, and alas, your browser does not support it.

This chapter introduces a number of designs where IKEv2 is used. Each design will use a simple deployment of two routers with the focus on the configuration of IKEv2. Although each scenario uses only two routers, the configuration can scale as required if needed.

The configuration is intended to be as simple as possible, and the emphasis is focused on the IKEv2 configuration.

Pre-shared-key Authentication with Smart Defaults

This configuration is the simplest to set up. By using smart defaults, a VPN is created between two peers using minimal configuration: only the IKEv2 profile and corresponding IKEv2 keyring are required.

Figure 7-1 illustrates the topology. The transport network is using IPv6, and the overlay network is using IPv4.

Figure 7-1PSK Authentication with Smart Defaults Topology

The following example illustrates the relevant configuration used on Router1. This is a very minimal configuration which leaves little room for error.

Note that the shared secrets used in the example below are for illustrative purposes and, if used in a production environment, should contain sufficient entropy.

The example might seem complex as this scenario uses IPv4 and IPv6; however, the main focus of interest is to illustrate the IKEv2 configuration and the simplicity of using smart defaults.

An IKEv2 keyring is created with a peer entry which matches the peer’s IPv6 address. Asymmetric pre-shared-keys are used with each device having a unique local and remote key.

The IKEv2 profile is the mandatory component and matches the remote IPv6 address configured on Router2. The local IKEv2 identity is set to the IPv6 address configured on E0/0. The authentication is set to pre-shared-key with the locally configured keyring defined previously.

The local loopback interface is configured, which will allow testing over the IPsec Security Association.

The tunnel interface is created as tunnel mode GRE IPv6. This is required as the transport network is IPv6 and the overlay is IPv4. The default IPsec profile is used to protect this interface; this uses the default IKEv2 profile which was configured earlier.

The physical interface used as the tunnel source uses IPv6.

Enhanced interior gateway routing protocol (EIGRP) is used to establish a peer relationship over the tunnel interface and distribute the loopback prefix.

The following example illustrates the relevant configuration on Router2.

The following example illustrates the EIGRP neighbor relationship built over the tunnel interface. The prefix for IP address assigned to the loopback interface on Router2 is reachable via the protected tunnel.

The following example illustrates the IKEv2 SA that is created. The IKEv2 SA is protected by the PRF and integrity algorithms using SHA512, encryption using AES-CBC-256, and Diffie-Hellman group 5, which are the most preferred algorithms within the IKEv2 default proposal. The authentication is performed using pre-shared-key.

The following example illustrates traffic being sent over the IPsec Security Association. The tunnel source and destination being the IPv6 addresses configured on the physical E0/0 interfaces.

Traffic is sent via the tunnel interface, from the locally configured loopback interface to the loopback on Router2.

The IPsec Security Association is verified where the default IPsec transform set is used, which is created using Encapsulation Security Payload with AES-CBC-256 for encryption and SHA1-HMAC for integrity. Transport mode is used.

Elliptic Curve Digital Signature Algorithm Authentication

The scenario looks to use digital signatures to authenticate both peers. Rather than the more common RSA certificates, Elliptic Curve (EC) certificates are used that provide the ability to authenticate both parties, using the Elliptic Curve Digital Signature Algorithm (ECDSA).

The configuration in this example is intended to be simple, with the main focus on the IKEv2 configuration.

Figure 7-2 illustrates the physical IP addressing and the setup of the tunnel interface.

In addition to ECDSA for authentication, Cisco Next Generation Encryption (NGE) algorithms secure the IKEv2 and IPsec session, as shown in Table 7-1.

Table 7-1Security Algorithms Used

Rather than using the default IKEv2 proposal, the default IKEv2 proposal is disabled, and a new IKEv2 proposal created containing the IKEv2 algorithms defined in Table 7-1.

Static routes are used to send traffic down the freshly created tunnel interface.

The following example illustrates the configuration that is used on Router1.

The trustpoint is configured using manual enrollment, with the local and CA certificate.

A certificate map is created that will match certificates containing a subject name of cisco.com. This is used within the IKEv2 profile to anchor the certificates presented by the peers. As this is a site-to-site VPN with only two peers, the certificate map could have been more granular to include the peer DN.

The default IKEv2 proposal is disabled, and a new IKEv2 proposal is created that contains the relevant cryptographic algorithms.

An IKEv2 policy is created, which encompasses the IKEv2 proposal created above. Because the default IKEv2 proposal is disabled, this then ensures that only the IKEv2 proposal named nge will be used and minimizes the chance of mis-configuration.

An IKEv2 profile is created, which uses the certificate map created earlier. The identity is set to DN, which will use the DN from the certificate. The authentication method is set to ECDSA and the PKI trustpoint used which was configured earlier. This profile will only match peer certificates, which contain the string cisco.com within the subject name. Dead-peer detection is enabled to ensure that the IKEv2 SA and corresponding IPsec Security Associations are torn down in a timely manner if IKE connectivity is lost.

An IPsec transform set is created, which uses AES-GCM-256. Because this is a combined mode cipher, no integrity algorithm is required.

The default IPsec profile is disabled, which ensures that it is not used due to mis-configuration. A new IPsec profile is created which uses the IKEv2 profile and IPsec transform-set created earlier. Additionally, perfect forward secrecy is enabled to ensure that a fresh Diffie-Hellman exchange is performed on rekey.

A loopback interface is used that will allow traffic to be sourced from and destined to as it transverses the VPN.

Bitcoin private and public key generator. The tunnel interface is created with the relevant source interface configured and with the destination address of Router2. This is protected by the IPsec profile created above.

The E0/0 interface is used as the tunnel source.

A static route is configured to send all traffic for the 192.168.20.0/24 network, which is the subnet protected by the peer, via the peer tunnel IP address.

Router2 has a nearly similar configuration; the following example illustrates the unique configuration. The tunnel interface has a unique IP address, and the destination is configured as E0/0 on Router1.

Note the unique IP address and the tunnel destination of Router1.

The following example illustrates verification that the IKEv2 SA established. The algorithms used to secure the IKE session as described in Table 7-1 can be seen.

The creation of the IPsec Security Association can be seen in the following example. The tunnel interface is configured with the default GRE mode, the traffic selectors can be seen indicating this by the use of IP protocol 47.

Wpa Pre Shared Key Linksys

The following example illustrates the route to 192.168.20.0/24, which be seen via the tunnel interface. All traffic intended for this network will be sent via the tunnel and encrypted by the corresponding IPsec Security Association.

Traffic is sent from Router1 to Router2 via the tunnel interface. Note that this traffic has been protected by the IPsec Security Association, as indicated by the increasing encaps and decaps counters.

RSA Authentication Using HTTP URL Lookup

In this scenario, we will use RSA certificates to authenticate both peers. However, for Router2, we will not send the certificate within the IKE AUTH exchange, but will send a HTTP URL from Router2 to Router1 to inform it where to obtain the certificate. Router1 will then retrieve the certificate from the HTTP URL and verify that the presented AUTH payload was signed by the private key relating to the public key contained within the certificate.

Router1 has been set up as a certificate authority; from this CA, a certificate is obtained for both Router1 and Router2. These certificates are used to authenticate the IKEv2 SA.

Figure 7-3 illustrates the operation of the HTTP URL lookup feature. Router2 will sign the AUTH payload with its private key. Router1 will retrieve the certificate from the HTTP server and validate the AUTH payload by using the public key obtained from the retrieved certificate.

Figure 7-3HTTP URL Lookup Feature

Figure 7-4 illustrates the topology used in the tunnel interface configuration.

The configuration is similar to the ECDSA example earlier, but RSA certificates are used, which results in a different authentication method. However, the base concepts are the same with regards to the PKI.

The subject information access (SIA) is an attribute within a certificate that defines some type of offered services. An example of where to access a server can be included in the SIA with a uniform resource identifier (URI). The SIA is amended to contain the URL that the peer will use for the HTTP URL lookup. This is achieved by the use of the certificate map that matches the locally used certificate and is attached to the trustpoint. This removes the inclusion of the certificate within the IKE exchange and uses the value defined in the SIA as the location for the peer to obtain the certificate.

The following example illustrates the configuration used on Router2.

The PKI trustpoint is defined; it has been authenticated, and the local device enrolled. The critical component to ensure that this client does not send its certificate but instead sends the HTTP URL is the match certificate command. This command will match the defined certificate map and override the SIA to contain the configured URL. This is then sent in replacement of the certificate in the IKE_AUTH exchange.

A certificate map is created that will match certificates containing a subject name of router1.cisco.com. This is used within the IKEv2 profile to anchor the peer’s presented certificate.

The following certificate map is used by the match statement within the trustpoint configuration to match the local certificate. This is achieved by matching the local subject name (which is not case sensitive) of router2.

The mandatory IKEv2 profile is configured which uses the certificate map created earlier. This will match any certificates which contain a subject name of cisco.com. The authentication method is set to RSA signatures, and the trustpoint configured earlier is used.

The tunnel interface is created with the relevant source interface configured and the destination address of Router1. This is protected by the default IPsec profile which uses the default IKEv2 profile which was created earlier.

The following physical interface is used as the tunnel source.

The following example illustrates the configuration used on Router1.

The certificate authority function is enabled. Note that the automatic granting of certificates is used here for ease of configuration and should not occur in a production environment where un-authenticated access to the CA can occur.

The relating PKI trustpoint for the IOS CA is:

A trustpoint is used to enroll into the local CA.

A certificate map is created that will match certificates containing a subject name of router2.cisco.com. This is used within the IKEv2 profile to anchor the peer’s presented certificate.

The mandatory IKEv2 profile is configured that uses the certificate map created earlier. This will match any certificates, which contain a subject name of cisco.com. The authentication method is set to RSA signatures, and the trustpoint configured earlier is used.

The tunnel interface is created with the relevant source interface configured, and the destination address of Router1. This is protected by the default IPsec profile that uses the default IKEv2 profile, which was created earlier.

The physical interface used as the tunnel source.

The physical interface used to reach the HTTP server containing the certificates.

The following example illustrates IKEv2 debugs taken from Router1. It can be seen that Router2 sends the IKE_AUTH exchange with the CERT payload containing the HASH and URL format. Also note the NOTIFY payload which indicates the HTTP URL method is supported.

A short time later, Router1 opens a TCP socket with 192.168.1.100, when the certificate is obtained.

The following example illustrates verification on Router1 that the certificate was obtained by way of HTTP.

The certificate that is obtained via HTTP is cached locally. By default, 200 certificates will be cached. As the certificate is cached, if the IKE session drops and is re-established, the certificate will not be required to be obtained via HTTP as it is already cached. This saves numerous HTTP requests to occur if the peer is required to re-authenticate. The following example illustrates viewing the contents of the certificate cache.

The following example illustrates the IKEv2 SA being verified. The cryptographic algorithms used have been negotiated via the use of smart defaults. The authentication method of RSA can be seen. There is no differentiation that the certificate was received via the HTTP URL method; the authentication is performed in the same manner as RSA authentication when certificates are sent in the IKE_AUTH exchange.

IKEv2 Cookie Challenge and Call Admission Control

The following scenario highlights the use of the cookie challenge and the maximum in negotiation SA features, and the benefits that each brings.

IKEv2 call admission control (CAC) limits the maximum number of IKEv2 SAs that can be established. CAC limits the number of simultaneous negotiations with the default being 40 in-negotiation SAs, although this value is configurable using the crypto ikev2 limit max-in-negotation-sa command.

To illustrate the CAC in action, the architecture in Figure 7-5 was developed. This setup consists of an IOS device acting as a VPN headend. Imagine a device created to send many IKE_SA_INIT requests to the headend from random spoofed source IP addresses. The IOS headend is configured with a default gateway, which is where all replies to any received IKE_SA_INIT messages will be sent and then discarded. The IKEv2 generator is pre-configured with an IKEv2 proposal that will be accepted by the IKEv2 headend and sends approximately 12 spoofed packets every second.

Figure 7-5CAC Architecture

The IKEv2 generator sends an IKE_SA_INIT request with a spoofed source IP address of 192.168.1.1 to 10.10.10.1. The IKEv2 headend receives the IKE_SA_INIT, checks that the transforms are valid, allocates state and returns its IKE_SA_INIT response. This response will be received by the router and then forwarded to the 192.168.1.1 destination where it will be discarded.

The hardware used for the IKEv2 headend was purposely chosen as a low-powered device. This was to illustrate the load when generating a large number Diffie-Hellman calculations and the software crypto engine was used. The following example illustrates the CPU history when a constant stream of spoofed IKEv2 SA_INIT requests is sent from the IKEv2 generator. The sudden initial spike in CPU (40 to 60 seconds) is due to the device processing the first forty spoofed IKE_SA_INIT requests, these are processed and replies sent. The CPU then drops to zero percent for approximately fifteen seconds and once again rises back to near full CPU at ninety percent. The drop in CPU processing was due to the CAC feature becoming active. Once forty IKE SAs are in negotiation, no more IKE_SA_INIT requests will be processed. Although the IKEv2 generator is sending a constant stream of these, the IKEv2 headend will only process forty at any given time (although this value is configurable). Some of the initial forty requests time out, and the state for these are removed before any new requests are processed and state allocated.

When an IKEv2 device acting as a responder receives a number of half-open IKE_SA_INIT requests, the cookie challenge mechanism can be deployed. This will enable the responder to include the cookie notification payload in the response to the initiator. The responder does not allocate any state to the session. If the initiator was legitimate, the response containing the cookie will reach the initiator who will then re-attempt the IKE_SA_INIT exchange, including the cookie notification payload, which is then verified by the responder. The responder will then allocate state to the IKE session.

Linksys Pre Shared Key

If a device is under a Denial-of-Service (DoS) attack where spoofed IKE_SA_INIT are sent with the purpose of overloading the CPU, the device can be configured to activate the cookie-challenge mechanism. In this situation, the responder will reply with the cookie notification payload. Because this reply is sent to an IP address that was spoofed by an attacker, this reply will be discarded, or dropped by the receiver.

To illustrate this behavior, the IKEv2 headend was amended to allow 1000 in negotiation SAs. The following example shows the command used to achieve this.

Cisco Asa Pre Shared Key Generator Reviews

The CPU of the IKEv2 headend was then constantly at 100 percent. This was due to the amount of constant spoofed IKE_SA_INIT requests from the IKEv2 generator that overwhelmed the IKEv2 state machine.

Cisco Asa Pre Shared Key Generator For Sale

To rectify this issue, the cookie-challenge is enabled by default. This was enabled, using the value of 0, so all received IKE_SA_INIT requests will be returned with the cookie notification payload.

Cisco Asa Pre Shared Key

The value configured can be between 0 and 1000, which denotes the maximum number of in-negotiation IKE SAs before the cookie challenge is engaged.

No state is allocated to any IKE sessions as all IKE_SA_INIT replies are resent. The following example illustrates the impact that enabling the cookie challenge mechanism has. Once cookie challenge is enabled, the CPU drops from 100 to 0 percent. This is due to the fact that no state is allocated to any of the received IKE_SA_INIT requests.

Cisco Asa Pre Shared Key Generator Download

The cookie challenge is a useful feature when an IKEv2 headend is under a DoS attack whereby source IP addresses are spoofed. It can be enabled by default. However, this will incur an additional two-packet exchange to any IKE negotiation which might not be optimal in some situations. Using a value for the maximum in negotiation SAs that is a little higher than what is observed in a known good state will allow this mechanism to engage should a DoS condition occur.