Cisco ASA Site-to-Site IPsec VPN CLI Configuration

The Cisco ASA remains one of the most common VPN gateways in enterprise and branch networks, and although ASDM and the newer management platforms offer point-and-click wizards, the site-to-site (LAN-to-LAN) configuration is still fastest and most reproducible on the CLI. The command model has five moving parts that must all line up: interface naming and security levels, an ISAKMP/IKE policy, a transform set, an interesting-traffic ACL, a tunnel-group holding the pre-shared key, and a crypto map that binds everything to the outside interface. Miss any one of them and the tunnel either refuses to come up or comes up and passes no traffic at all. Because every step has a visible artefact you can inspect - an SA, a policy, a bound map - the CLI is also the best place to learn how IPsec actually fits together rather than treating the wizard as a black box. This guide follows the official Cisco ASA VPN CLI configuration guide step by step and shows a complete working example you can adapt to your own addressing.

Step 1: Configure Interfaces (Inside/Outside)

An ASA will not negotiate a VPN until its interfaces are named, addressed and have a security level. The nameif command is what turns a physical port into a logical security zone, and it can only be applied while the interface has no address configured, so do it first. The inside interface gets the highest security level, the outside gets zero, and any DMZ typically sits between them. Security levels drive the default implicit ACL behaviour: traffic from a higher level to a lower one is permitted by default, traffic in the other direction is not. The vpn tunnel itself will always be built from the outside interface.

hostname(config)# interface gigabitethernet0/0
hostname(config-if)# nameif outside
hostname(config-if)# security-level 0
hostname(config-if)# ip address 203.0.113.1 255.255.255.248
hostname(config-if)# no shutdown
hostname(config-if)# exit
hostname(config)# interface gigabitethernet0/1
hostname(config-if)# nameif inside
hostname(config-if)# security-level 100
hostname(config-if)# ip address 192.168.1.1 255.255.255.0
hostname(config-if)# no shutdown

Confirm the result with show interface ip brief. Security levels matter because they drive the default ACL behaviour between zones, and the ASA uses the interface name (not the port number) everywhere later in the VPN configuration. The outside address shown here (203.0.113.1) is the one the remote peer must target as its tunnel destination, so it must be a static, publicly reachable address. If the ASA sits behind another NAT device you will need to forward UDP 500 and UDP 4500 to it, or the peer's ISAKMP packets will never arrive.

Step 2: Configure the IKEv1 Policy and Enable ISAKMP

Phase 1 defines how the two peers authenticate each other and protect the negotiation channel. The policy number is only a local identifier, but both devices must agree on the actual attributes - authentication method, encryption, hash, Diffie-Hellman group and lifetime. A mismatch on any single attribute means the two sides never find a common proposal and Phase 1 fails with a "no matching policy" or "proposal not chosen" message in the logs.

hostname(config)# crypto ikev1 policy 1
hostname(config-ikev1-policy)# authentication pre-share
hostname(config-ikev1-policy)# encryption aes
hostname(config-ikev1-policy)# hash sha
hostname(config-ikev1-policy)# group 2
hostname(config-ikev1-policy)# lifetime 43200
hostname(config-ikev1-policy)# exit
hostname(config)# crypto ikev1 enable outside

The policy is useless until IKE is enabled on the interface that terminates the tunnel - that is what the crypto ikev1 enable outside line does. If you skip it, the ASA silently ignores incoming ISAKMP packets from the peer, which is the single most common reason a tunnel never reaches MM_SA_SETUP. Note also that you can define several policies with different priorities and let the peers negotiate down the list; the lower the priority number, the earlier it is offered. For interoperability with older third-party gear, add a second policy with 3DES and SHA1, but keep AES as the preferred one.

Step 3: Create the Transform Set and Interesting-Traffic ACL

The transform set describes Phase 2 protection: which encryption and integrity algorithms protect the payload inside the tunnel. The interesting-traffic ACL (crypto ACL) defines exactly which packets are encrypted and sent through the tunnel - any packet that does not match it is forwarded normally, in the clear. Together these two objects answer "what is protected" and "how is it protected".

hostname(config)# crypto ipsec ikev1 transform-set FirstSet esp-aes esp-sha-hmac
hostname(config)# access-list l2l_list extended permit ip 192.168.1.0 255.255.255.0 10.10.4.0 255.255.255.0

The ACL defines exactly which traffic enters the tunnel - local source subnet to remote destination subnet. It must mirror the peer's ACL, or the tunnel will establish but pass no traffic. Read the entries as "source = my local subnet, destination = the remote subnet I want to reach". The remote ASA will have the reverse entry (10.10.4.0/24 to 192.168.1.0/24). If either side is more specific than the other, the negotiation succeeds but the encaps counters stay flat. A useful trick is to make an "any any" crypto ACL while troubleshooting a new tunnel to prove that the negotiation works, then tighten it to the real subnets once it passes traffic.

Step 4: Define the Tunnel Group with the Pre-Shared Key

The tunnel-group binds the peer address to its connection attributes, including the pre-shared key used in Phase 1 authentication. It is the per-peer policy container, and a single ASA can hold many of them.

hostname(config)# tunnel-group 10.10.4.108 type ipsec-l2l
hostname(config)# tunnel-group 10.10.4.108 ipsec-attributes
hostname(config-tunnel-ipsec)# ikev1 pre-shared-key 44kkaol59636jnfx

The tunnel-group name must be the IP address of the remote peer. Use the same pre-shared key on the far-end ASA, which references this device's public IP. The type keyword ipsec-l2l is what distinguishes a site-to-site peer from a remote-access one; if you omit it the ASA will treat the peer as a client and Phase 1 will fail authentication. Treat the key as a non-guessable secret and rotate it on a schedule, because it protects the entire tunnel. In production, consider replacing the pre-shared key with certificates so that a lost key cannot be replayed, and note that the key is stored in clear text in the running configuration.

Step 5: Build the Crypto Map and Apply It

The crypto map is the glue. It tells the ASA "when traffic matches this ACL, talk to this peer using this transform set", and it must be bound to the outside interface to take effect. The map ties the four previous objects into a single ordered rule set.

hostname(config)# crypto map abcmap 1 match address l2l_list
hostname(config)# crypto map abcmap 1 set peer 10.10.4.108
hostname(config)# crypto map abcmap 1 set ikev1 transform-set FirstSet
hostname(config)# crypto map abcmap interface outside
hostname(config)# write memory

The sequence number after the map name (1) allows several peers to share one map - just use a different sequence for each peer. Applying the map to an interface clears and re-establishs existing sessions, so schedule the change in a maintenance window on production gear. You can also add a second peer with set peer on the same sequence for redundancy, in which case the ASA tries the first and falls back to the second. Finally, write memory (or copy running-config startup-config) is not optional: a reload without it loses the entire configuration.

NAT Exemption: The Step Everyone Forgets

On modern ASA software (8.3 and later) every packet is evaluated against NAT rules before it can match a crypto ACL. If your outside interface has a dynamic PAT rule (the default behaviour on many templates), the ASA will translate the tunnel traffic's source address and then fail to find a matching crypto ACL entry, so no tunnel is built. You must carve out the VPN traffic with an identity NAT (NAT exemption) rule so that the interesting traffic leaves untranslated:

hostname(config)# object network LOCAL_NET
hostname(config-network-object)# subnet 192.168.1.0 255.255.255.0
hostname(config-network-object)# object network REMOTE_NET
hostname(config-network-object)# subnet 10.10.4.0 255.255.255.0
hostname(config)# nat (inside,outside) source static LOCAL_NET LOCAL_NET destination static REMOTE_NET REMOTE_NET

This tells the ASA to send that traffic untranslated so the crypto ACL can catch it. A missing NAT exemption produces the classic symptom: show crypto ipsec sa shows no SAs, the tunnel never comes up, and a packet-tracer run reveals the traffic being PAT'd out of the outside interface. If your ASA is still on 8.2 or earlier, the equivalent is a nonat access-list referenced from a nat (inside) 0 access-list line. On both software trains, the exemption must be more specific than the general PAT rule or it will never be matched.

Using IKEv2 Instead of IKEv1

For IKEv2 peers, replace the policy and transform-set steps with crypto ikev2 policy, an ikev2 ipsec-proposal, and crypto map ... set ikev2 ipsec-proposal secure - the ACL and tunnel-group structure stay the same, but the tunnel-group now uses ikev2 local-authentication pre-shared-key and ikev2 remote-authentication pre-shared-key instead of the single IKEv1 key. IKEv2 is more robust across NAT, supports multiple subnets per SA natively, and is the version you should choose for any new deployment. It also negotiates faster and recovers from lost rekeys more gracefully, which matters on unstable WAN links.

Verification Commands

hostname# show crypto isakmp sa
hostname# show crypto ipsec sa
hostname# show crypto map
hostname# show vpn-sessiondb l2l

In show crypto ipsec sa, check that both inbound and outbound encaps/decaps counters increase when you ping across the tunnel. A state of MM_ACTIVE in show crypto isakmp sa means Phase 1 is healthy; if the IPsec SAs show 0 packets encapsulated, the problem is almost always a mismatched or missing crypto ACL. Use packet-tracer input inside icmp 192.168.1.10 8 0 10.10.4.10 to see exactly which NAT, ACL and crypto steps a test packet hits - it is the single most effective troubleshooting command on the platform. For live negotiation detail, run debug crypto ikev1 127 and debug crypto ipsec 127 from a console or syslog session, never in the middle of a busy SSH window.

Common Failure Modes and Fixes

• No ISAKMP SA at all: IKE not enabled on the interface, wrong peer IP, or a perimeter firewall blocking UDP 500/4500.
• Phase 1 fails with "no matching policy": mismatched encryption, hash, DH group or pre-shared key between the two ends.
• Tunnel up, no traffic: crypto ACLs do not mirror each other, or the NAT exemption is missing.
• Works until the first rekey: lifetime mismatch, or the peer is behind a device that drops the rekey exchange.
• One direction only: the remote side's ACL uses the wrong source subnet, or routing sends return traffic elsewhere.
• Flapping tunnel: check for asymmetric routing and for duplicate crypto maps across multiple physical interfaces.

Related Guides on This Site

Start from the basics with Cisco ASA CLI basics: interfaces, ACLs and NAT, and compare with FortiGate IPsec setup or Juniper SRX route-based IPsec when you run multi-vendor VPNs. If the tunnel is not coming up at all, work through our IPsec IKEv2 debugging guide, which walks through the debug output step by step.

原文链接：https://www.cisco.com/c/en/us/td/docs/security/asa/asa916/configuration/vpn/asa-916-vpn-config/vpn-site2site.html