PDF(1.8 MB) View with Adobe Reader on a variety of devices
ePub(77.3 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(85.8 KB) View on Kindle device or Kindle app on multiple devices
Updated:June 22, 2015
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to enable the Adaptive Security Appliance (ASA) to accept dynamic IPsec site-to-site 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 Remote-ASA end only. The Central-ASA cannot initiate a VPN tunnel because of the dynamic IPsec configuration. The IP address of Remote-ASA is unknown.
Configure Central-ASA in order to dynamically accept connections from a wild-card IP address (0.0.0.0/0) and a wild-card pre-shared key. Remote-ASA is then configured to encrypt traffic from local to Central-ASA subnets as specified by the crypto access-list. Both sides perform Network Address Translation (NAT) exemption in order to bypass NAT for IPsec traffic.
There are no specific requirements for this document.
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.
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 Pre-shared Key:
Choose Configuration > Site-to-Site 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 Dynamic-map with matching transform-set (IPsec Proposal). Click Add.
In the Create IPsec Rule window, from the Tunnel Policy (Crypto Map) - Basic tab, choose outside from the Interface drop-down list and dynamic from the Policy Type drop-down list. In the Priority field, assign the priority for this entry in case there are multiple entries under Dynamic-Map. Next, click Select next to the IKE v1 IPsec Proposal field in order to select the IPsec proposal.
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.
From the Tunnel Policy (Crypto Map)-Advanced tab, check the Enable NAT-T 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 pre-shared key (cisco123 in this example) configured on the remote peer needs to match with one under DefaultL2LGroup.
Choose Configuration > Site-to-Site VPN > Advanced > Tunnel Groups, select DefaultL2LGroup, click Edit and configure the desired pre-shared key. Click OK when you are done.
Note: This creates a wildcard pre-shared key on the static peer (Central-ASA). Any device/peer who knows this pre-shared key and its matching proposals can successfully establish a VPN tunnel and access resources over VPN. Ensure this pre-skared key is not shared with unknown entities and is not easy to guess.
Choose Configuration > Site-to-Site VPN > Group Policies and select the group-policy of your choice (default group-policy in this case). Click Edit and edit the group policy in the Edit Internal Group Policy dialog box. Click OK when you are done.
Choose Configuration > Firewall > NAT Rules and from the Add Nat Rule window, configure a no nat (NAT-EXEMPT) rule for VPN traffic. Click OK when you are done.
Remote-ASA (Dynamic Peer)
Choose Wizards > VPN Wizards > Site-to-site VPN Wizard once the ASDM application connects to the ASA.
Choose outside from the VPN Access Interface drop-down 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.
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.
Enter the authentication information to use, which is pre-shared key in this example. The pre-shared key used in this example is cisco123. The Tunnel Group Name is the remote peer IP address by default if you configure LAN-to-LAN (L2L) VPN.
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:
From the Authentication Methods tab, enter the IKE version 1 pre-shared Key in the Pre-shared Key field. In this example, it is cisco123.
Click the Encryption Algorithms tab.
Click Manage next to the IKE Policy field, click Add and configure a custom IKE Policy (phase-1). Click OK when you are done.
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.
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 drop-down list in order to set the interface where local network is reachable. Click Next.
ASDM displays a summary of the VPN just configured. Verify and click Finish.
Central ASA (Static Peer) Configuration
Configure a NO-NAT/ NAT-EXEMPT rule for VPN traffic as this example shows:
clear crypto ikev1 sa <peer IP address> Clears the Phase 1 SA for a specific peer.
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 vpn-sessiondb logoff tunnel-group <tunnel-group-name> command in order to clear IKE and IPsec SAs for a single tunnel.
Remote-ASA#vpn-sessiondb logoff tunnel-group 172.16.2.1 Do you want to logoff the VPN session(s)? [confirm] INFO: Number of sessions from TunnelGroup "172.16.2.1" logged off : 1
clear crypto ipsec sa peer <peer IP address> !!! Clears the required Phase 2 SA for specific peer. debug crypto condition peer < Peer address> !!! Set IPsec/ISAKMP debug filters. debug crypto isakmp sa <debug level> !!! Provides debug details of ISAKMP SA negotiation. debug crypto ipsec sa <debug level> !!! Provides debug details of IPsec SA negotiations undebug all !!! To stop the debugs