Overview
This chapter will show you how to set up an IPSec site-to-site connection with your appliance. The topics covered previously in Chapter 15 on ISAKMP Phase 1 apply to this chapter, since site-to-site, commonly called LAN-to-LAN (L2L), connections must first establish a management connection. The topics covered in this chapter include
-
Preparing for your site-to-site connections
-
Configuring ISAKMP Phase 2, including crypto ACLs, transform sets, and crypto maps
-
Verifying site-to-site connectivity
-
A site-to-site configuration example
Site-to-Site Preparation
Cisco security appliances have supported IPSec L2L connections since version 5 of the operating system. Before you begin setting up L2L connections on your appliances, you should first go through some basic preparation by determining the following:
-
How the management connection should be protected
-
The identity type of the peer: address or name
-
The authentication method used: pre-shared keys or certificates
-
Whether address translation is needed because of overlapping addresses
-
What data traffic should be protected and how it should be protected
-
What interface(s) L2L connections will terminate on
One thing you’ll need to do is exempt the IPSec traffic flowing from a lower- to higher- security-level interface:
ciscoasa(config)# sysopt connection permit-vpn
| Tip | If you forget this command, you can still terminate connections on the appliance; however, traffic will be unable to flow inbound without either this command or an ACL configuration on the interface the tunnel is terminated on that allows the inbound decrypted traffic. |
The remaining subsections in this section will review what was covered in Chapter 15, focusing on what you’ll need for ISAKMP/IKE Phase 1 for L2L connections.
| Note | For a large number of L2L connections, I recommend that you use Cisco routers. Cisco routers support GRE tunnels and dynamic multipoint VPNs (DMVPNs): the combination of these two features provides a much more scalable solution than the appliances offer. I typically use appliances for L2L connections when I have a small number of sites that I don’t anticipate expanding on. |
ISAKMP Phase 1 Configuration
Here is a quick synopsis of the ISAKMP Phase 1 commands you need to configure for L2L connections:
ciscoasa(config)# crypto isakmp enable logical_if_name
ciscoasa(config)# crypto isakmp identity {address | hostname |
key string | auto }
ciscoasa(config)# crypto isakmp policy policy_number
ciscoasa(config-isakmp-policy)# authentication {pre-share | rsa-sig |
crack}
ciscoasa(config-isakmp-policy)# encryption {3des | aes | aes-192 |
aes-256 | des}
ciscoasa(config-isakmp-policy)# group {1 | 2 | 5 | 7}
ciscoasa(config-isakmp-policy)# hash {md5 | sha}
ciscoasa(config-isakmp-policy)# lifetime {seconds | none} These commands were discussed in Chapter 15. IPSec is typically enabled on the outside interface (connected to the Internet) with the crypto isakmp enable command. Normally the identity type is the IP address of the remote peer, which means that you don’t have to configure the crypto isakmp address command (unless this is not the case).
You’ll need at least one matching ISAKMP policy with the remote peer. Remember that the policy number is important: this is the order that the appliance sends the policies to the remote peer during the Phase 1 negotiation. Therefore, make sure the lowest-numbered policy has the most secure parameters (like RSA signatures, AES encryption, SHA HMAC function, Diffie-Hellman key group 5, and a lifetime of 1 hour) and that the highest-numbered policy has the least-secure parameters (like pre-shared keys, DES encryption, MD5 HMAC function, Diffie-Hellman key group 1, and a lifetime of 1 day).
| Note | Normally, site-to-site connections do not travel through translation or firewall devices, and thus NAT-T and/or IPSec over TCP is not needed. However, if this is not the case, you’ll need to configure these options on the appliance. |
Tunnel Group Configuration
For a site-to-site connection, the tunnel group type must be “ipsec-l2l”, where the “l2l” part is “L-2-L”, not “one-two-one.” Here’s the syntax to create the tunnel group:
ciscoasa(config)# tunnel-group tunnel_group_ID type ipsec-l2l
Based on the identity type for ISAKMP Phase 1, you’ll need to configure an appropriate tunnel group identifier. For example, if the identity type is “address,” then the tunnel group identifier is the publicly reachable IP address of the remote peer; if the identity type is “hostname,” then the group identifier is the fully qualified domain name of the remote peer, where this must be resolvable by either a static DNS entry (name command) or a DNS server.
No general attributes apply to L2L tunnel groups; however, there are IPSec-specific ones. Here’s the syntax to configure the IPSec-specific tunnel group attributes for L2L connections:
ciscoasa(config)# tunnel-group peer_IP_addr ipsec-attributes
ciscoasa(config-tunnel-ipsec)# pre-shared-key key
ciscoasa(config-tunnel-ipsec)# peer-id-validate {cert | nocheck | req}
ciscoasa(config-tunnel-ipsec)# trust-point name_of_CA
ciscoasa(config-tunnel-ipsec)# isakmp keepalive threshold seconds
retry seconds
If you’ll be using a pre-shared key, configure it in the tunnel group with the pre-shared-key command: the maximum length of the key is 128 characters. If you are using certificates, use the peer-id-validate command to specify their usage:
-
cert If both peers support certificates and the use of certificates is negotiated during Phase 1, then certificates will be used; otherwise pre-shared keys will be used.
-
nocheck Certificates are not used with this tunnel group.
-
req Certificates must be used with this tunnel group or the L2L tunnel will fail.
The trust-point command specifies the name of the CA to use—it indicates what identity certificate to use if more than one CA and identity certificate are installed on the appliance. The name specified here needs to match the name configured with the crypto ca trust-point command discussed in Chapter 15; however, this command is unnecessary if the appliance has only one root and identity certificate, since it will use these by default.
To enable Dead Peer Detection (DPD), use the isakmp keepalive command. The first threshold is the number of seconds between keepalives (10 to 3600), and the retry interval is how long the appliance should wait after the first keepalive is missed and the second one should be sent (2–10 seconds). DPD is disabled by default.
| Note | DPD sends keepalives across the management connection, allowing the appliance to detect a dead management connection. Because this is Cisco-proprietary, it should only be enabled for a tunnel group that has Cisco devices for remote peers. |
VPN Traffic and Address Translation
If your appliance is performing address translation on addresses as traffic goes to the public network or you have the nat-control command configured, requiring address translation, you will probably want to exempt translation for the traffic traversing the site-to-site VPN; if you recall from Chapter 5, this is referred to as Identity NAT. The exception to this is an extranet L2L where there might be overlapping addresses between the two companies.
Use the following syntax to implement identity NAT for your intranet L2L traffic:
ciscoasa(config)# nat 0 access-list ACL_ID
In the ACL, use permit statements to exempt the site-to-site traffic—include both the source and destination addresses/networks.
As an example, examine the network shown in Figure 16-1. In this network, an Intranet IPSec L2L tunnel is being used, and address translation is not needed when traffic goes between the two sites. Here’s the Identity NAT configuration for asa1 to exempt the traffic from translation:
asa1(config)# access-list ACLnonat permit ip 10.0.1.0 255.255.255.0
10.0.2.0 255.255.255.0
asa1(config)# nat (inside) 0 access-list ACLnonat
Figure 16-1: Address translation and crypto ACL example
ISAKMP Phase 2 Configuration
This next section will focus on configuring the appliance so that the data connections, commonly called security associations (SAs), for an L2L connection can be built to a remote IPSec peer. You must complete three tasks:
-
Configure a crypto ACL, which determines what data traffic is to be protected.
-
Create a transform set, which determines how the data traffic is to be protected.
-
Create a crypto map entry for the remote peer, which brings all the parameters together for the associated peer.
The following sections will cover these required configurations, as well as optional ones.
| Note | If you’ve configured these items on a Cisco IOS router before, then the syntax used by the appliances is either the same or very similar, making it easy to build IPSec L2L tunnels. |
Crypto ACLs
Crypto ACLs are used to define what data traffic should be protected by the IPSec tunnel. Crypto ACLs are also used on Cisco IOS routers. Unlike a normal ACL, a crypto ACL doesn’t filter traffic: it defines what data traffic (Phase 2) is or isn’t protected by the IPSec tunnel. A permit statement in an ACL entry specifies traffic to be protected, and a deny statement (or the implicit deny) specifies traffic that should not be protected. You need to be as specific as possible when specifying the traffic that is to be protected...in other words, you definitely do not want to specify a source address and mask of 0.0.0.0 0.0.0.0 (or 0 0 for short), because this means that all traffic coming into the IPSec interface on the appliance is expected to be protected. The appliance, in this situation, will drop all traffic that is not supposed to be protected, but based on your configuration, is expected to be protected, like Internet users’ web traffic for your DMZ web server.
| Note: | For each remote site, you’ll need a separate crypto ACL. |
Crypto ACLs should be mirrored or symmetrical between the two peers. For example, if you have two networks, network A and network B, on the network A side the crypto ACL would be to protect traffic from A to B; however, on the network B side, the crypto ACL would be to protect traffic from B to A. Going back to Figure 16-1, here’s the asa1 crypto ACL statement:
asa1(config)# access-list 102 permit ip 10.0.1.0 255.255.255.0
10.0.2.0 255.255.255.0
And here’s the asa2 crypto ACL statement:
asa2(config)# access-list 201 permit ip 10.0.2.0 255.255.255.0
10.0.1.0 255.255.255.0
Notice that the network numbers are reversed in the two crypto ACLs.
| Tip | If the crypto ACLs aren’t mirrored between the two peers, you typically see a mismatched proxy condition in your logs or debug output. This indicates you have nonsymmetrical crypto ACLs on the two peers. |
Transform Sets
A transform set defines the properties (transforms) as to how a data connection can be protected. A transform set has three parameters: two transforms and a mode. Here are the commands to create a transform set:
ciscoasa(config)# crypto ipsec transform-set set_name [{esp-3des |
esp-aes | esp-aes-192 | esp-aes-256 |
esp-des | esp-null}] [{esp-md5-hmac |
esp-sha-hmac | esp-none}]
ciscoasa(config)# crypto ipsec transform-set set_name mode
{tunnel | transport} The first command defines how the data traffic is to be protected. You must give the transform set a locally significant name; in other words, the name you give the set doesn’t have to match what is configured on the remote peer. The transform set name is followed by an encryption algorithm and/or an HMAC function, commonly called the transforms. The order that you enter the transforms doesn’t matter. Notice that you don’t have to use an encryption algorithm (esp-null) or an HMAC function (esp-none).
| Note | You can have multiple transform sets for different peers—this is necessary if you have different peers with different capabilities. For example, you might have one peer that supports AES 256, but another that only supports 3DES. In this situation, you would need two transform sets for the two respective peers. |
The second command defines the mode for the data connections. Data connections support two modes: tunnel and transport. Tunnel mode is used for L2L and remote access connections, and transport mode for point-to-point connections, like the appliance sending a syslog message to a syslog server. If you don’t configure this second command, the mode defaults to tunnel for the data connections using this transform set. If you are using a point-to-point connection, then you would specify transport as the mode in the second command.
Connection Lifetimes
Optionally you can globally change the timeout values for your data SAs. (You can also override the global timeout on a peer-by-peer basis in a crypto map entry, discussed in the next section.) Once these timeouts are reached, the appliance will either rekey them or tear them down and rebuild the SAs.
Here’s the syntax to change the global SA timers:
ciscoasa(config)# crypto ipsec security-association
lifetime seconds seconds
ciscoasa(config)# crypto ipsec security-association lifetime
kilobytes kilobytes
The default lifetimes are 3600 seconds (one hour) and 4,608,000KB of traffic sent across the SA. Changing the timeout values with the preceding commands affects only newly built SAs; existing SAs will use the timeout values that previously existed when the SAs were built.
Crypto Maps
A crypto map defines the parameters to build tunnels to peers. Each peer you want to build a tunnel to needs to be referenced as a separate entry in the crypto map. The entry binds together all of the necessary components to form an SA with a remote peer.
Crypto maps come in two varieties: static and dynamic. Static crypto maps are used when you know who you are connecting to, what traffic needs protecting, and how it should be protected. Static crypto maps are commonly used in L2L connections. Dynamic crypto maps are used when you don’t know all three of these things. Dynamic crypto maps are most commonly used on a VPN gateway accepting IPSec remote access connections (I discuss this in Chapter 17).
An entry in a static crypto map must include the following information:
-
The crypto ACL that defines which traffic is to be protected (encrypted/authenticated)
-
Which site you are connecting to (the identity of the peer at the remote site)
-
What transform set should be used to protect your traffic to the remote peer
Other information can be configured in a crypto map, like the lifetime values of the data SAs and perfect forward secrecy (PFS), but these other configurations are optional.
Crypto Map Entries
This chapter only focuses on static crypto maps. To create an entry in a static crypto map, use the crypto map command. Typically you will only have one map that you will activate on the interface connected to the public network. However, if you have different divisions or companies that you are connecting with the appliance, you might need to create multiple maps, one for each interface. To distinguish one map from another, you give it a unique name. Crypto map names are locally significant and don’t have to match between peers.
Here is the syntax for creating an entry in a static crypto map:
ciscoasa(config)# crypto map map_name entry_# match address ACL_ID
ciscoasa(config)# crypto map map_name entry_# set
transform-set set_name
ciscoasa(config)# crypto map map_name entry_# set
peer IP_address_or_name
ciscoasa(config)# crypto map map_name entry_# set
pfs {group1 | group2 | group5 | group7}
ciscoasa(config)# crypto map map_name entry_# set phase1-mode
{main | aggressive}
ciscoasa(config)# crypto map map_name entry_# set trustpoint
trustpoint_name
ciscoasa(config)# crypto map map_name entry_# set security-association
{seconds seconds | kilobytes kilobytes}
ciscoasa(config)# crypto map map_name entry_# set connection-type
{answer-only | bidirectional | originate-only} A crypto map is made up of one or more entries. If you have more than one location you are connecting to, you’ll need an entry for each location within the crypto map. For example, if you had three sites you were connecting to off the same interface, you would have three entries for the crypto map used on that interface. Each entry in a crypto map needs a unique entry_# or priority number (or what Cisco often refers to as a sequence number). This number is used to group together the parameters that will be used to negotiate an SA with a remote peer. If your crypto map has multiple entries, when the appliance is performing its negotiation, it always looks for the highest priority match between the policy information of each peer. The lower the number for the entry, the higher the priority, where 1 has the highest priority.
| Note | The configuration of crypto maps is slightly different on an appliance compared with an IOS router. On an appliance, all the crypto map commands are configured in global configuration mode. On IOS routers, each entry you create in the crypto map takes you into a subcommand mode where you complete the configuration for the associated peer. To activate the crypto map on a router, you perform this from interface subcommand mode. |
You must specify the identity of the remote peer. Based on the configuration of the crypto isakmp identity command, you’ll either enter the IP address or hostname of the remote peer with the set peer parameter. If you have two peers at a remote location, a primary and a backup, configure this command twice, where the first set peer parameter specifies the primary and the second the backup.
| Note | If you put both remote peers at a location in separate crypto map entries, the appliance can actually build two tunnels (one to each peer), instead of one. |
Second, you must also specify which traffic is protected by referencing the crypto ACL that you previously created with the match address parameter in a crypto map entry. And third, you must reference the name of a transform set (or sets) in the set transform-set parameter in a crypto map entry. You can specify up to nine transform set names in one command—just list them one right after the other. You might need to reference more than one transform set name if you are unsure how the remote peer is configured for a transform set.
The rest of the parameters in a crypto map entry are optional. Optionally you can specify the use of Perfect Forward Secrecy (PFS). By default the keying information for the data connections (the keys for the encryption and HMAC functions) are shared across the existing protected management connection. PFS performs Diffie-Hellman (DH) a second time for the keying information for the data connections. If you want to use PFS for a peer, configure the set pfs parameter in a crypto map entry. When configuring this parameter, you need to specify the DH key group that will be used, which must match what the remote peer has configured.
| Note | The advantage of PFS is that it is more secure than the management connection; the disadvantage of PFS is that it slows the building of the data connections. |
The optional set phase1-mode parameter specifies what mode should be used (aggressive or main) during ISAKMP Phase 1 when building the management connection to the peer. If you don’t configure this value, main mode is used if certificates are used for authentication, and aggressive mode is used if pre-shared keys are used.
The optional set trustpoint parameter specifies the name of the CA trustpoint, and thus the identity certificate, to use if certificates are used during Phase 1 for authentication. Starting in version 7.0, the preferred method is to configure this within a tunnel group.
Optionally you can change the lifetimes for the data connections associated with this peer by configuring the set security-association parameter. The defaults are based on the configuration of the global timeout commands configured with the crypto ipsec security-association lifetime, discussed earlier.
forces the local appliance to establish the tunnel.
| Note | If you change the parameters in a crypto map entry, the changes don’t affect any existing data SAs—you must tear down the existing ones (or wait till they expire) before the changes take effect. |
Crypto Map Activation
Once you have created your crypto map and its entries, you need to apply the crypto map to an interface on the appliance. This is accomplished with the crypto map interface command:
ciscoasa(config)# crypto map map_name interface logical_if_name
Typically the crypto map will be applied to the interface connected to the public network, like the outside interface. Once you apply the crypto map, the appliance will begin building tunnels and processing IPSec traffic. Also, you can only apply one crypto map to an interface. To view your crypto map commands, use the show run crypto map command.
| Note | Tunnels will not be built until traffic needs to be sent to a remote site that matches a crypto ACL associated with a crypto map entry. |
