Config Asa9x Ike Ipsec 00 PDF
Config Asa9x Ike Ipsec 00 PDF
Config Asa9x Ike Ipsec 00 PDF
Configuration Example
Document ID: 119007
Contributed by Santhosha Shetty, Rahul Govindan, and Adesh Gairola,
Cisco TAC Engineers.
Jun 22, 2015
Contents
Introduction
Prerequisites
Requirements
Components Used
Configure
Network Diagram
ASDM Configuration
CentralASA (Static Peer)
RemoteASA (Dynamic Peer)
CLI Configuration
Central ASA (Static Peer) Configuration
RemoteASA (Dynamic Peer)
Verify
Central ASA
RemoteASA
Troubleshoot
RemoteASA (Initiator)
CentralASA (Responder)
Related Information
Introduction
This document describes how to enable the Adaptive Security Appliance (ASA) to accept dynamic IPsec
sitetosite VPN connections from any dynamic peer (ASA in this case). As the Network Diagram in this
document shows, the IPsec tunnel is established when the tunnel is initiated from the RemoteASA end only.
The CentralASA cannot initiate a VPN tunnel because of the dynamic IPsec configuration. The IP address of
RemoteASA is unknown.
Configure CentralASA in order to dynamically accept connections from a wildcard IP address (0.0.0.0/0)
and a wildcard preshared key. RemoteASA is then configured to encrypt traffic from local to
CentralASA subnets as specified by the crypto accesslist. Both sides perform Network Address Translation
(NAT) exemption in order to bypass NAT for IPsec traffic.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
The information in this document is based on Cisco ASA (5510 and 5520) Firewall Software Release 9.x and
later.
The information in this document was created from the devices in a specific lab environment. All of the
devices used in this document started with a cleared (default) configuration. If your network is live, make sure
that you understand the potential impact of any command.
Configure
Note: Use the Command Lookup Tool (registered customers only) in order to obtain more information on the
commands used in this section.
Network Diagram
ASDM Configuration
CentralASA (Static Peer)
On an ASA with a Static IP address, set up the VPN in such a way that it accepts dynamic connections from
an unknown peer while it still authenticates the peer using an IKEv1 Preshared Key:
1. Choose Configuration > SitetoSite VPN > Advanced > Crypto Maps. The window displays the
list of crypto map entries which are already in place (if there is any). Since ASA does not know what
the Peer IP address is, in order for ASA to accept the connection configure Dynamicmap with
matching transformset (IPsec Proposal). Click Add.
2. In the Create IPsec Rule window, from the Tunnel Policy (Crypto Map) Basic tab, choose outside
from the Interface dropdown list and dynamic from the Policy Type dropdown list. In the Priority
field, assign the priority for this entry in case there are multiple entries under DynamicMap. Next,
click Select next to the IKE v1 IPsec Proposal field in order to select the IPsec proposal.
3. When the Select IPsec Proposals (Transform Sets) dialog box opens, choose among the current IPsec
proposals or click Add in order to create a new one and use the same. Click OK when you are done.
4. From the Tunnel Policy (Crypto Map)Advanced tab, check the Enable NATT check box (required
if either peer is behind a NAT device) and the Enable Reverse Route Injection check box. When the
VPN tunnel comes up for the dynamic peer, ASA installs a dynamic route for the negotiated remote
VPN network that points to the VPN interface.
Optionally, from the Traffic Selection tab you can also define the interesting VPN traffic for the
dynamic peer and click OK.
As mentioned earlier, since ASA does not have any information about the remote dynamic peer IP
address, the unknown connection request lands under DefaultL2LGroup which exists on ASA by
default. In order for authentication to succeed the preshared key (cisco123 in this example)
configured on the remote peer needs to match with one under DefaultL2LGroup.
5. Choose Configuration > SitetoSite VPN > Advanced > Tunnel Groups, select DefaultL2LGroup,
click Edit and configure the desired preshared key. Click OK when you are done.
Note: This creates a wildcard preshared key on the static peer (CentralASA). Any device/peer who
knows this preshared key and its matching proposals can successfully establish a VPN tunnel and
access resources over VPN. Ensure this preskared key is not shared with unknown entities and is not
easy to guess.
6. Choose Configuration > SitetoSite VPN > Group Policies and select the grouppolicy of your
choice (default grouppolicy in this case). Click Edit and edit the group policy in the Edit Internal
Group Policy dialog box. Click OK when you are done.
7. Choose Configuration > Firewall > NAT Rules and from the Add Nat Rule window, configure a no
nat (NATEXEMPT) rule for VPN traffic. Click OK when you are done.
RemoteASA (Dynamic Peer)
1. Choose Wizards > VPN Wizards > Sitetosite VPN Wizard once the ASDM application connects to
the ASA.
2. Click Next.
3. Choose outside from the VPN Access Interface dropdown list in order to specify the outside IP
address of the remote peer. Select the interface (WAN) where the crypto map is applied. Click Next.
4. Specify the hosts/networks that should be allowed to pass through the VPN tunnel. In this step, you
need to provide the Local Networks and Remote Networks for the VPN Tunnel. Click the buttons
next to the Local Network and Remote Network fields and choose the address as per requirement.
Click Next when you are done.
5. Enter the authentication information to use, which is preshared key in this example. The preshared
key used in this example is cisco123. The Tunnel Group Name is the remote peer IP address by
default if you configure LANtoLAN (L2L) VPN.
OR
You can customize the configuration to include the IKE and IPsec policy of your choice. There needs
to be at least one matching policy between the peers:
a. From the Authentication Methods tab, enter the IKE version 1 preshared Key in the
Preshared Key field. In this example, it is cisco123.
b. Click the Encryption Algorithms tab.
6. Click Manage next to the IKE Policy field, click Add and configure a custom IKE Policy (phase1).
Click OK when you are done.
7. Click Select next to the the IPsec Proposal field and select the desired IPsec Proposal. Click Next
when you are done.
Optionally, you can go to the Perfect Forward Secrecy tab and check the Enable Perfect Forward
Secrecy (PFS) check box. Click Next when you are done.
8. Check the Exempt ASA side host/network from address translation check box in order to prevent the
tunnel traffic from the start of Network Address Translation. Choose either local or inside from the
dropdown list in order to set the interface where local network is reachable. Click Next.
9. ASDM displays a summary of the VPN just configured. Verify and click Finish.
CLI Configuration
Central ASA (Static Peer) Configuration
1. Configure a NONAT/ NATEXEMPT rule for VPN traffic as this example shows:
Verify
Use this section to confirm that configuration works properly.
The Output Interpreter Tool (registered customers only) supports certain show commands. Use the Output
Interpreter Tool in order to view an analysis of show command output.
show crypto isakmp sa Displays all current IKE Security Associations (SAs) at a peer.
show crypto ipsec sa Displays all current IPsec SAs.
This section shows example verification outout for the two ASAs.
Central ASA
CentralASA#show crypto isakmp sa
IKEv1 SAs:
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
RemoteASA
RemoteASA#show crypto isakmp sa
IKEv1 SAs:
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
172.16.2.1
1 IKE Peer:
Type : L2L Role
initiator
:
Rekey : no State
MM_ACTIVE
:
show crypto
RemoteASA#
ipsec sa
interface: outside
Crypto map
outside_map,
tag: seq num: 1, local addr: 172.16.1.1
Troubleshoot
This section provides information you can use in order to troubleshoot your configuration.
The Output Interpreter Tool (registered customers only) supports certain show commands. Use the Output
Interpreter Tool in order to view an analysis of show command output.
Note: Refer to Important Information on Debug Commands before you use debug commands.
Caution: The clear crypto isakmp sa command is intrusive as it clears all active VPN tunnels.
In PIX/ASA software release 8.0(3) and later, an individual IKE SA can be cleared using the clear crypto
isakmp sa <peer ip address>command. In software releases earlier than 8.0(3), use the vpnsessiondb logoff
tunnelgroup <tunnelgroupname> command in order to clear IKE and IPsec SAs for a single tunnel.
Debugs used:
RemoteASA (Initiator)
Enter this packettracer command in order to initiate the tunnel:
CentralASA (Responder)
Jan 20 12:42:35 [IKEv1]IP = 172.16.1.1, IKE_DECODE RECEIVED Message (msgid=0)
with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) +
VENDOR (13) + NONE (0) total length : 172
:
.
Jan 20 12:42:35 [IKEv1]IP = 172.16.1.1, IKE_DECODE SENDING Message (msgid=0)
with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + NONE (0) total length
:
132
Jan 20 12:42:35 [IKEv1]IP = 172.16.1.1, IKE_DECODE RECEIVED Message (msgid=0)
with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13)
+ VENDOR (13) + NATD (20) + NATD (20) + NONE (0) total length : 304
:
.
Jan 20 12:42:35 [IKEv1]IP = 172.16.1.1, Connection landed on tunnel_group
DefaultL2LGroup
Jan 20 12:42:35 [IKEv1 DEBUG]Group = DefaultL2LGroup, IP = 172.16.1.1,
Generating keys for Responder...
Jan 20 12:42:35 [IKEv1]IP = 172.16.1.1, IKE_DECODE SENDING Message (msgid=0)
with payloads : HDR + KE (4) + NONCE (10) +
VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NATD (20) + NATD (20) +
NONE (0) total length : 304
Jan 20 12:42:35 [IKEv1]IP = 172.16.1.1, IKE_DECODE RECEIVED Message (msgid=0)
with payloads : HDR + ID (5) + HASH (8)
+ IOS KEEPALIVE (128) + VENDOR (13) + NONE (0) total length : 96
Jan 20 12:42:35 [IKEv1 DECODE]Group = DefaultL2LGroup, IP = 172.16.1.1,
ID_IPV4_ADDR ID received 172.16.1.1
:
.
Jan 20 12:42:35 [IKEv1]IP = 172.16.1.1, IKE_DECODE SENDING Message (msgid=0)
with payloads : HDR + ID (5) + HASH (8) + IOS KEEPALIVE (128) +
VENDOR (13) + NONE (0) total length : 96
Jan 20 12:42:35 [IKEv1]Group = DefaultL2LGroup, IP = 172.16.1.1, PHASE 1 COMPLETED
:
.
Jan 20 12:42:35 [IKEv1 DECODE]IP = 172.16.1.1, IKE Responder starting QM:
msg id = c45c7b30
Jan 20 12:42:35 [IKEv1]IP = 172.16.1.1, IKE_DECODE
RECEIVED Message (msgid=c45c7b30) with payloads : HDR + HASH (8) + SA (1) +
NONCE (10) + ID (5) + ID (5) + NOTIFY (11) + NONE (0) total length : 200
:
.
Jan 20 12:42:35 [IKEv1]Group = DefaultL2LGroup, IP = 172.16.1.1, Received remote
IP Proxy Subnet data in ID Payload: Address 10.1.1.0, Mask 255.255.255.0,
Protocol 0, Port 0 :
.
Jan 20 12:42:35 [IKEv1]Group = DefaultL2LGroup,
IP = 172.16.1.1, Received local
IP Proxy Subnet data in ID Payload: Address 10.1.2.0, Mask 255.255.255.0,
Protocol 0, Port 0 Jan 20 12:42:35 [IKEv1 DEBUG]Group = DefaultL2LGroup,
IP = 172.16.1.1, processing notify payload
Jan 20 12:42:35 [IKEv1] Group = DefaultL2LGroup, IP = 172.16.1.1, QM
IsRekeyed old sa not found by addr
Jan 20 12:42:35 [IKEv1]Group = DefaultL2LGroup, IP = 172.16.1.1, Static Crypto Map
check, map outside_dyn_map, seq = 1 is a successful match
Jan 20 12:42:35 [IKEv1]Group = DefaultL2LGroup, IP = 172.16.1.1, IKE
Remote Peer configured for crypto map: outside_dyn_map
:
.
Jan 20 12:42:35 [IKEv1 DEBUG]Group = DefaultL2LGroup, IP = 172.16.1.1,
Transmitting Proxy Id: Remote subnet: 10.1.1.0 Mask 255.255.255.0 Protocol 0 Port 0
Local subnet: 10.1.2.0 mask 255.255.255.0 Protocol 0 Port 0 :
.
Jan 20 12:42:35 [IKEv1]IP = 172.16.1.1, IKE_DECODE SENDING Message (msgid=c45c7b30)
with payloads : HDR + HASH (8) + SA (1) + NONCE (10) + ID (5) + ID (5) + NONE
(0) total length : 172 Jan 20 12:42:35 [IKEv1]IP = 172.16.1.1, IKE_DECODE RECEIVED
Message (msgid=c45c7b30) with payloads : HDR + HASH (8) + NONE (0) total length : 52:
.
Jan 20 12:42:35 [IKEv1]Group = DefaultL2LGroup, IP = 172.16.1.1, Security
negotiation complete for LANtoLAN Group (DefaultL2LGroup) Responder,
Inbound SPI = 0x38da6e51, Outbound SPI = 0x30d071c0 :
.
Jan 20 12:42:35 [IKEv1]Group = DefaultL2LGroup, IP = 172.16.1.1,
PHASE 2 COMPLETED (msgid=c45c7b30)
Jan 20 12:42:35 [IKEv1]Group = DefaultL2LGroup, IP = 172.16.1.1, Adding static
route for L2L peer coming in on a dynamic map. address: 10.1.1.0, mask: 255.255.255.0
Related Information
Cisco ASA Series Command References
IPsec Negotiation/IKE Protocols Support Page
Requests for Comments (RFCs)
Technical Support & Documentation Cisco System
Updated: Jun 22, 2015 Document ID: 119007