Networking-Blog

My WordPress Blog

Configuring and Applying Crypto Maps

Last Updated on Mon, 22 Aug 2022 | IPSEC

After configuring crypto access lists and transform sets, you can add them to a crypto map.

Consider the network in Figure 7-12 with two routers that peer over an untrustcd network. Assume that IKJi, crypto access lists, and transform sets are configured and a crypto map is now needed.

Figure 7-12 A Network with a Basic Crypto Map Configuration

San Francisco

San Francisco

Figure 7-12 A Network with a Basic Crypto Map Configuration

Crypto Maap

New York s1:192.168.1.1

MAP-TO-NY (crypto map)

MAP-TO-SF (crypto map)

New York s1:192.168.1.1

MAP-TO-NY (crypto map)

MAP-TO-SF (crypto map)

In the preceding diagram, Router A’s serial interface to the untrusted network is 192.168.1.1.

A crypto map named MAP-TO-NY is applied to this interface (the configuration commands follow). Likewise, Router B’s serial interface is 192.168.1.2 and has a crypto map called MAP-TO-SF.

The following commands create a crypto map on Router A (for clarity, the context of the IOS prompt is included):

RTA#conf t

Enter configuration commands, one per line. End with CNTL/Z. RTA(config)#crypto map MAP-TO-NY 20 ipsec-isakmp RTA(config-crypto-map)#match address 101

RTA(config-crypto-map)#set transform-set TRANS-ESP TRANS-AH-ESP

RTA(config-crypto-map)#set peer 192.168.1.2

RTA(config crypto-map)#exit

RTA(config)#int si

RTA(config-if)#crypto map MAP-TO-NY

The command crypto map MAP-TO-NY 20 ipsec-isakmp creates a crypto map entry with a sequence of 20 for a crypto map called MAP-TO-NY (the crypto map is created when its first entry is created ). Although this example contains just one entry, crypto maps may contain multiple entries to designate multiple peers, transform sets, and access lists. The sequence number prioritizes the crypto map entries. As the router compares packets to the crypto map, it examines entries in the order of their sequence number (lower sequence numbers are examined first). For this example, a sequence of 20 was chosen so that future entries may be placed before or after this entry. The keyword ipsec-isakmp indicates that IKE is used to manage the SAs for this entry.

IOTE In addition to IKE, which is specified by the ipsec-isakmp keyword, ciypto maps support two other options: ipsec-manual (IPsec without IKE) and cisco (Cisco’s pre-IPsec encryption feature called Cisco Encryption Technology, or CET). Consult the IOS documentation for configuring ipsec-manual or cisco.

The command match address 101 assigns crypto access lisl 101 to this entry. Outbound packets that match this list are protected with IPsec. Inbound packets that match the reverse logic of the list are expected to be protected.

The command set transform-set TRANS-ESP TRANS-AH-ESP defines the transform sets that are acceptable for protecting the traffic covered by the crypto access list. When negotiating IPsec SAs with the remote peer (Router B), the router proposes transform sets in the order listed by this command (this router’s first choice is the transform set TRANS-ESP). Router A and Router B must agree to use a common transform set (a common set of protocols and algorithms) before an SA can be established. TRANS-ESP and TRANS-AH-ESP are the names of transform sets previously created by the crypto ipsec transform-set command. The transform set names (TRANS-ESP, TRANS-AH-ESP) are locally significant and do not have to be the same on both routers.

The command set peer 192.168.1.2 defines the remote peer, Router B, with which this router builds the IPsec S A and to which it subsequently sends the protected traffic. Multiple peers can be configured by repeating the set peer command. This provides a level of redundancy for when SAs are established: If the first peer is not reachable, the router attempts to establish the SA with the next peer in the entry.

The interface configuration command crypto map MAP-TO-NY applies the crypto map to the router’s Serial 1 interface (selected by the command int si). Like access lists, crypto maps do not do anything until you apply them to an interface. The proper place to apply the crypto map is the interface where the protected traffic exits the router: the interface that points in the direction of the remote peer. In this example. Router A’s Serial 1 interface is the exit point (refer to Figure 7-12).

The following is the corresponding configuration on Router B (only the relevant crypto map lines are shown):

RTB#sh run

Current configuration: hostname RTB

<lines deleted for brevity> I

crypto map MAP-TO-SF 20 ipsec-isakmp match address 102

set transform-set B-TRANS1 B-TRANS2 set peer 192.168.1.1

interface Seriall ip address 192.168.1.2 255.255.255.0 crypto map MAP-TO-SF

The crypto access list 102 must be a mirror image of list 101 on Router A, and at least one of the transform sets (B-TRANS1 or B-TRANS2) must match one of Router A’s transform sets (TRANS-ESP and TRANS-AH-ESP). A match means the transform sets share the same protocols (AH, ESP) and algorithms (DES or MD5, for example).

NOTE Crypto access lists arc crypto map elements and interoperate with regular packet-filtering access lists that might exist on an interface. Packets blocked by regular access lists are not processed by IPsec.

Continue reading here: Configuring IPsec SA Lifetimes

CISCO IOS SPOKE – IPSEC ISAKMP vs IPSEC ISAKMP PROFILE

IPSEC ISAKMP : CISCO REMOTE SITE :


crypto isakmp policy 1

encr aes
hash md5
authentication pre-share
group 2
lifetime 3600
!
crypto isakmp key t35t1n5!!! address 85.234.92.94
crypto isakmp keepalive 10
crypto isakmp nat keepalive 10
!
!
crypto ipsec transform-set 3G_IPSEC esp-3des esp-sha-hmac
!
!
!
!
crypto map mapping 1 ipsec-isakmp
set peer 85.234.92.94
set security-association lifetime seconds 86400
set security-association idle-time 86400
set transform-set 3G_IPSEC
set pfs group2
match address VPN
!
interface Dialer0
crypto map mapping
!
!
ip access-list extended VPN
permit ip 192.168.0.0 0.0.0.255 any
!
!

IPSEC ISAKMP PROFILE :

crypto isakmp policy 10
encr aes
hash md5
authentication pre-share
group 2
lifetime 3600
!
crypto keyring TEST_VPN
local-address dialer0
pre-shared-key address 85.234.92.94 key t35t1n5!!!
!
crypto isakmp profile TEST_VPN
keyring TEST_VPN
match identity address 85.234.92.94
local-address dialer0
!
crypto ipsec transform-set 3G_IPSEC esp-3des esp-sha-hmac
mode tunnel
!
crypto map 3G-1 10 ipsec-isakmp
set security-association lifetime seconds 900
set peer 85.234.92.94
set pfs group2
set transform-set 3G_IPSEC
set isakmp-profile TEST_VPN
match address TEST_VPN
!
!
ip access-list extended TEST_VPN
permit ip 192.168.0.0 0.0.0.255 any
!
interface Dialer0
crypto map 3G-1

How IPSec Works

How IPSec Works

IPSec involves many component technologies and encryption methods.
Yet IPSec’s operation can be broken down into five main steps:

  1. “Interesting traffic” initiates the IPSec process. Traffic is deemed interesting when the IPSec
    security policy configured in the IPSec peers starts the IKE process.
  2. IKE phase 1. IKE authenticates IPSec peers and negotiates IKE SAs during this phase,
    setting up a secure channel for negotiating IPSec SAs in phase 2.
  3. IKE phase 2. IKE negotiates IPSec SA parameters and sets up matching IPSec SAs in the peers.
  4. Data transfer. Data is transferred between IPSec peers based on the IPSec parameters and
    keys stored in the SA database.
  5. IPSec tunnel termination. IPSec SAs terminate through deletion or by timing out.

This five-step process :

The five steps of IPSec for dummies like Mufty:

Step 1—Defining Interesting Traffic

What type of traffic is deemed interesting is determined as part of formulating a security
policy for use of a VPN. The policy is then implemented in the configuration interface for
each particular IPSec peer.

For example, in Cisco routers and PIX Firewalls, access lists are used to determine the
traffic to encrypt. The access lists are assigned to a cryptography policy;
the policy’s
permit statements indicate that the selected traffic must be encrypted, and deny statements
indicate that the selected traffic must be sent unencrypted
. With the Cisco Secure VPN Client, you
use menu windows to select connections to be secured by IPSec. When interesting traffic is generated
or transits the IPSec client, the client initiates the next step in the process
,
negotiating an IKE phase 1 exchange.

Defining “interesting traffic.”

Step 2—IKE Phase 1

The basic purpose of IKE phase 1 is to authenticate the IPSec peers and to set up a secure channel
between the peers to enable IKE exchanges. IKE phase 1 performs the following functions:

  • Authenticates and protects the identities of the IPSec peers
  • Negotiates a matching IKE SA policy between peers to protect the IKE exchange
  • Performs an authenticated Diffie-Hellman exchange with the end result of having matching
    shared secret keys
  • Sets up a secure tunnel to negotiate IKE phase 2 parameters

IKE phase 1 occurs in two modes: main mode and aggressive mode.
These modes are described in the following sections.

Main Mode

Main mode has three two-way exchanges between the initiator and the receiver.

  • First exchange: The algorithms and hashes used to secure the IKE communications are
    agreed upon in matching IKE SAs in each peer.
  • Second exchange: Uses a Diffie-Hellman exchange to generate shared secret keying material
    used to generate shared secret keys and to pass nonces—random numbers sent to the other
    party and then signed and returned to prove their identity.
  • Third exchange: Verifies the other side’s identity. The identity value is the IPSec peer’s IP address
    in encrypted form. The main outcome of main mode is matching IKE SAs between peers to provide
    a protected pipe for subsequent protected ISAKMP exchanges between the IKE peers.
    The IKE SA specifies values for the IKE exchange: the authentication method used, the encryption
    and hash algorithms, the Diffie-Hellman group used, the lifetime of the IKE SA in seconds or kilobytes,
    and the shared secret key values for the encryption algorithms.
    The IKE SA in each peer is bi-directional
    .

Aggressive Mode

In aggressive mode, fewer exchanges are made, and with fewer packets. On the first exchange,
almost everything is squeezed into the proposed IKE SA values: the Diffie-Hellman public key;
a nonce that the other party signs; and an identity packet, which can be used to verify identity
via a third party.

The receiver sends everything back that is needed to complete the exchange. The only thing left is
for the initiator to confirm the exchange. The weakness of using the aggressive mode is that both sides
have exchanged information before there’s a secure channel. Therefore, it’s possible to “sniff” the wire and
discover who formed the new SA. However,
it is faster than main mode.

Step 3—IKE Phase 2

The purpose of IKE phase 2 is to negotiate IPSec SAs to set up the IPSec tunnel.
IKE phase 2 performs the following functions:

  • Negotiates IPSec SA parameters protected by an existing IKE SA
  • Establishes IPSec security associations
  • Periodically renegotiates IPSec SAs to ensure security
  • Optionally performs an additional Diffie-Hellman exchange

IKE phase 2 has one mode, called quick mode. Quick mode occurs after IKE has established the
secure tunnel in phase 1. It negotiates a shared IPSec policy, derives shared secret keying material
used for the IPSec security algorithms, and establishes IPSec SAs. Quick mode exchanges nonces
that provide replay protection. The nonces are used to generate new shared secret key material and
prevent replay attacks from generating bogus SAs.

Quick mode is also used to renegotiate a new IPSec SA when the IPSec SA lifetime expires.
Base quick mode is used to refresh the keying material used to create the shared secret key based on the
keying material derived from the Diffie-Hellman exchange in phase 1.

Perfect Forward Secrecy

If perfect forward secrecy (PFS) is specified in the IPSec policy, a new Diffie-Hellman
exchange is performed with each quick mode, providing keying material that has
greater entropy (key material life) and thereby greater resistance to cryptographic attacks.
Each Diffie-Hellman exchange requires large exponentiations, thereby increasing CPU use
and exacting a performance cost.

Step 4—IPSec Encrypted Tunnel

After IKE phase 2 is complete and quick mode has established IPSec SAs, information is exchanged via
an IPSec tunnel. Packets are encrypted and decrypted using the encryption specified in the IPSec SA
.

IPSec encrypted tunnel.

Step 5—Tunnel Termination

IPSec SAs terminate through deletion or by timing out. An SA can time out when a
specified number of seconds have elapsed or when a specified number of bytes have passed through
the tunnel. When the SAs terminate, the keys are also discarded. When subsequent IPSec SAs are
needed for a flow, IKE performs a new phase 2 and, if necessary, a new phase 1 negotiation.
A successful negotiation results in new SAs and new keys. New SAs can be established before the
existing SAs expire, so that a given flow can continue uninterrupted.

Cisco IPSEC Pre-fragmentation VPN’s

Feature Overview

When a packet is nearly the size of the maximum transmission unit (MTU) of the outbound link of the
encrypting router, and it is encapsulated with IPSec headers, it is likely to exceed the
MTU of the
outbound link.

This causes packet fragmentation after encryption, which makes the decrypting router reassemble
in the process path.
Pre-fragmentation for IPSec VPNs increases the decrypting router’s performance
by enabling it to operate in the high performance CEF path instead of the process path.

Pre-fragmentation for IPSec VPNs enables an encrypting router to pre-determine the encapsulated
packet size
from information available in transform sets, which are configured as part of the
IPSec security association (SA). If it is pre-determined that the packet will exceed the MTU of the
output interface, the packet is fragmented before encryption.

This avoids process level reassembly before decryption and helps improve decryption performance and
overall IPSec traffic throughput
.

Benefits

Increased Performance
Delivers encryption throughput at maximum encryption hardware accelerator speeds.
This performance increase is for near MTU sized packets.

Uniform Fragmentation
Packets are fragmented into equally sized units to prevent further downstream fragmentation.

Restrictions

Take the following information into consideration before this feature is configured:

Pre-fragmentation for IPSec VPNs is on by default.
Pre-fragmentation for IPSec VPNs operates in IPSec Tunnel mode and IPSec tunnel mode with GRE,
but not with IPSec transport mode.

Pre-fragmentation for IPSec VPNs configured on the decrypting router in a unidirectional traffic scenario
does not improve the performance or change the behavior of either of the peers.
Pre-fragmentation for IPSec VPNs occurs before the transform is applied if compression is turned
on for outgoing packets
.

Pre-fragmentation for IPSec VPNs functionality depends on the egress interface crypto ipsec df-bit
configuration and the incoming packet “do not fragment” (DF) bit state. See Table .

You may want use the clear setting for the DF bit when encapsulating tunnel mode IPSec traffic
so you can send packets larger than the available MTU size or if you do not know what the available
MTU size
is.

clear Specifies that the outer IP header will have the DF bit cleared and that the router may fragment the packet to add
the IPSec encapsulation.
set Specifies that the outer IP header will have the DF bit set; however, the router may fragment the packet if the
original packet had the DF bit cleared
.
copy Specifies that the router will look in the original packet for the outer DF bit setting.
Table 1 Pre-fragmentation For Ipsec VPNs Dependencies

Enabled crypto ipsec df-bit clear 0 Fragmentation occurs before encryption.
Enabled crypto ipsec df-bit clear 1 Fragmentation occurs before encryption.
Disabled crypto ipsec df-bit clear 0 Fragmentation occurs after encryption and packets are reassembled
before decryption
.
Disabled crypto ipsec df-bit clear 1 Fragmentation occurs after encryption and packets are reassembled before decryption.
Enabled crypto ipsec df-bit set 0 Fragmentation occurs before encryption.
Enabled crypto ipsec df-bit set 1 Packets are dropped.
Disabled crypto ipsec df-bit set 0 Fragmentation occurs after encryption and packets are reassembled before decryption.
Disabled crypto ipsec df-bit set 1 Packets are dropped.
Enabled crypto ipsec df-bit copy 0 Fragmentation occurs before encryption.
Enabled crypto ipsec df-bit copy 1 Packets are dropped.
Disabled crypto ipsec df-bit copy 0 Fragmentation occurs after encryption and packets are reassembled before decryption.
Disabled crypto ipsec df-bit copy 1 Packets are dropped.

Cisco IPSEC PFS

Perfect Forward Secrecy (PFS)

 —PFS ensures that a given IPsec SA key was not derived from any other secret, like some other keys. In other words, if someone breaks a key, PFS ensures that the attacker is not able to derive any other key. If PFS is not enabled, someone can potentially break the IKE SA secret key, copy all the IPsec protected data, and then use knowledge of the IKE SA secret in order to compromise the IPsec SAs setup by this IKE SA. With PFS, breaking IKE does not give an attacker immediate access to IPsec. The attacker needs to break each IPsec SA individually. The Cisco IOS IPsec implementation uses PFS group 1 (D-H 768 bit) by default.

Cisco GRE over IPSEC

GRE is a tunneling protocol used to transport packets from one network through another network.

If this sounds like a virtual private network (VPN) to you, that’s because it theoretically is: Technically, a GRE tunnel is a type of a VPN—but it isn’t a secure tunneling method. However, you can encrypt GRE with an encryption protocol such as IPSec to form a secure VPN.

In fact, the point-to-point tunneling protocol (PPTP) actually uses GRE to create VPN tunnels.

For example, if you configure Microsoft VPN tunnels, by default, you use PPTP, which uses GRE

Local Network Configuration :

crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 2
crypto isakmp key test address 2.2.2.2 no-xauth
crypto isakmp keepalive 15 5
!
!
crypto ipsec transform-set COMMTRANSIT esp-aes esp-sha-hmac
!
crypto ipsec profile COMMS 
set transform-set COMMTRANSIT
!
!
interface Tunnel0
 ip unnumbered GigabitEthernet0/0
 keepalive 10 3
 tunnel source 1.1.1.1
 tunnel destination 2.2.2.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile COMMS
!
!
interface GigabitEthernet0/0
 description COMMS-PRIMARY
 ip address 10.10.10.1 255.255.255.0
 ip nat inside
 ip inspect myfw in
 ip virtual-reassembly
 duplex auto
 speed auto
!
!
interface GigabitEthernet0/1
 ip address 1.1.1.1 255.255.255.0
 ip nat outside
 ip virtual-reassembly
 duplex auto
 speed auto
!
!
router rip
 version 2
 network 10.0.0.0
!
ip route 10.10.11.0 255.255.255.0 Tunnel0
!

Remote Network Configuration :

crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 2
crypto isakmp key test address 1.1.1.1 no-xauth
crypto isakmp keepalive 15 5
!
!
crypto ipsec transform-set COMMTRANSIT esp-aes esp-sha-hmac
!
crypto ipsec profile COMMS 
set transform-set COMMTRANSIT
!
!
interface Tunnel0
 ip unnumbered GigabitEthernet0/0
 keepalive 10 3
 tunnel source 2.2.2.2
 tunnel destination 1.1.1.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile COMMS
!
!
interface GigabitEthernet0/0
 description COMMS-SECONDARY
 ip address 10.10.11.1 255.255.255.0
 ip nat inside
 ip inspect myfw in
 ip virtual-reassembly
 duplex auto
 speed auto
!
!
interface GigabitEthernet0/1
 ip address 2.2.2.2 255.255.255.0
 ip nat outside
 ip virtual-reassembly
 duplex auto
 speed auto
!
!
router rip
 version 2
 network 10.0.0.0
!
ip route 10.10.10.0 255.255.255.0 Tunnel0

Linux Zyxel Ipsec VPN Configuration

Zyxel Router Linux Config.

Phase 1 (IKE) = Lifetime   8Hrs
Phase 2 (IPSEC) = Keylife 24hrs

86400  = 24hrs = Seconds
28800  = 8hrs    = Seconds
1440     = 24hrs  = Minutes
480       = 8hrs     = Minutes

Linux Ipsec Directory Conf :

conn commtest
type=tunnel
authby=secret
auth=esp
esp=3des-md5-96
left= “Remote Peer Address”
leftsubnet= “Remote Subnet Address”
right=”Local Wan Address”
rightsubnet= “Local Subnet Address”
keyingtries=3
pfs=yes
rekey=yes
auto=start
keyexchange=ike
ikelifetime=8h
keylife=24h
dpdaction=restart
dpddelay=30
dpdtimeout=120

ipsec.secrets.conf

80.74.16.251 1.1.1.1 : PSK “commsvpn”
80.74.16.251 1.1.1.2 : PSK “commsvpn”
80.74.16.251 1.1.1.3 : PSK “commsvpn”
80.74.16.251 1.1.1.4 : PSK “commsvpn”
80.74.16.251 1.1.1.5 : PSK “commsvpn”

Rereadsecrets Command Forces OpenSWAN to reload the secrets from the ipsec.secrets file

sudo ipsec auto –rereadsecrets

Cisco Ipsec Site-Site VPN

Cisco Ipsec Site-Site VPN Configuration :

Local Site :

crypto isakmp policy 1
 encr aes
 hash sha
 authentication pre-share
 group 2
crypto isakmp key test address 1.1.1.1
!
crypto ipsec transform-set comms esp-aes esp-sha-hmac
!
crypto map comms 1 ipsec-isakmp
 set peer 2.2.2.2
 set transform-set comms
 match address 102
!
access-list 102 permit ip 10.10.10.0 0.0.0.255 172.0.0.0 0.31.255.255
                              (Lan Ip)             (Remote Subnet)
!
!
access-list 101 deny ip 10.10.10.0 0.0.0.255 172.0.0.0 0.31.255.255
       (Deny Traffic to be NaTed over the VPN Link)
access-list 101 permit ip 10.10.10.0 0.0.0.255 any
       (Permit Local Traffic to be NaTed)
!
!
ip nat inside source list 101 interface Dialer0 overload
!
interface FA0/0
 description Connectioon_to_WAN
 ip address 1.1.1.1 255.255.255.0
 ip access-group INTERNET in
 ip nat outside
 crypto map comms
!
interface FA0/1
 description Connection_to_LAN
 ip address 10.10.10.1 255.255.255.0
 ip nat inside
!
ip access-list extended INTERNET
permit esp host 2.2.2.2 any
permit udp host 2.2.2.2 any eq isakmp
!
end

Remote Site :
crypto isakmp policy 1
 encr aes
 hash sha
 authentication pre-share
 group 2
crypto isakmp key test address 2.2.2.2
!
crypto ipsec transform-set comms esp-aes esp-sha-hmac
!
crypto map comms 1 ipsec-isakmp
 set peer 1.1.1.1
 set transform-set comms
 match address 102
!
access-list 102 permit ip 172.0.0.0 0.31.255.255 10.10.10.0 0.0.0.255
                               (Lan Ip)             (Remote Subnet)
!
!
access-list 101 deny ip 172.0.0.0 0.31.255.255 10.10.10.0 0.0.0.255
      (Deny Traffic to be NaTed over the VPN Link)
access-list 101 permit ip 172.0.0.0 0.31.255.255 any
      (Permit Local Traffic to be NaTed)
!
!
ip nat inside source list 101 interface Dialer0 overload
!
interface FA0/0
description Connectioon_to_WAN
ip address 2.2.2.2 255.255.255.0
ip access-group INTERNET in
ip nat outside
crypto map comms
!
interface FA0/1
description Connection_to_LAN
ip address 172.16.1.1 255.255.255.0
ip nat inside
!
ip access-list extended INTERNET
permit esp host 1.1.1.1 any
permit udp host 1.1.1.1 any eq isakmp
!
end

VPN Tweaks :

config terminal

crypto isakmp keepalive 15 10
!
crypto map comms securewan 1 ipsec-isakmp
set security-association lifetime kilobytes 18432000
set security-association lifetime seconds 86400
set security-association idle-time 7200

2 Types of VPN Encryption :

crypto ipsec transform-set esp-aes esp-md5-hmac
crypto ipsec transform-set esp-aes esp-sha-hmac
!
crypto isakmp policy 1
 hash md5
 hash sha

Guide to Cisco ASA VPN

To get your VPN going you will need the following parts in your configuration:

– an access-list defining interesting traffic
– an access-list exempting your VPN traffic from NAT (NAT0)
– a crypto IPSec transform-set defining your IPSec encryption
– a crypto map defining the actual IPSec tunnel
– a crypto isakmp policy to define your ‘negotiation settings’ for phase 1.
– a tunnel-group defining attributes to the tunnel

When troubleshooting you should make sure that the above parts are present in your config. If they are you are usually well underway.

Next, make sure that your NAT exempt access-list is actually referenced (see under the NAT0 chapter), that your crypto map is correctly applied to an interface (see the crypto map chapter) and that isakmp is globally enabled (see the isakmp policy chapter).

I will now cover all the separate steps one by one and try to give an explanation of what each part does and what it should look like .They order in which I reference the different commands is not necessarily the best order to configure a VPN tunnel. I’ve chosen this order because this is the order in which it will appear in a config, hopefully making it easier when troubleshooting to step by step go through your config and see if all is setup correctly.

1. [Interesting traffic]
——————–
When creating a VPN tunnel you have to tell the ASA which traffic must be sent through the tunnel. The traffic which goes through is called “interesting traffic”. You create this selection using an access-list.

On a site to site VPN you configure both sides of the tunnel. Be aware that you create an access-list on each side and that they actually mirror each other. On the first site you tell the ASA you want to tunnel traffic from the main site to the branch office. On the other you are on the branch site so you tell the ASA to tunnel traffic from the branch site to the main site.
It might seem obvious, but it’s quite often overlooked.

Let’s create the commands to see how it looks:

access-list VPN_cryptomap extended permit ip 10.0.0.0 255.255.255.0 192.168.0.0 255.255.255.0

As you can see this is an access-list created on the Main office as it tells the ASA that traffic from the 10.0.0.0 network to the 192.168.0.0 network should be put into the tunnel. All other traffic will not be treated as interesting for the tunnel and will proceed the normal way through the ASA.

Now let’s look at the access-list that you would use on the branch site:

access-list VPN_cryptomap extended permit ip 192.168.0.0 255.255.255.0 10.0.0.0 255.255.255.0

Note again how the traffic selection is reversed to select traffic specifically going from the branch office to the main office.

Of course this is just the actual defining of interesting traffic. It is not yet related to an action at this point. The ASA will select the traffic as you specify and then shrug and just let it pass as usual. We will define an action to the selection later on when configuring the crypto map.

2. [NAT0]
——————–
Since you directly connect the main and branch sites you generally do not need to NAT the traffic between the locations. As you have most likely setup some kind of NAT for your Internet connection and the like you will need to exempt the traffic which needs to go through the tunnel from being NATted.

To do this we will again use an access-list:

access-list Inside_nat0_outbound extended permit ip 10.0.0.0 255.255.255.0 192.168.0.0 255.255.255.0

Just like with the interesting traffic we have just selected the traffic at this point. We now need to tell the ASA what to do with the traffic it sees. In this case we create a statement to do “NAT0”. Which means… “don’t NAT”.

nat (Inside) 0 access-list Inside_nat0_outbound

Notice that we use the ‘nat’ statement as you would normally, connecting it to an interface. We come from the inside interface, so that’s where the statement should be. Then you provide a number where you would normally put the pool number of the global that you define on the other side. In this case we use 0 to tell the ASA there is no pool and just don’t use NAT at all. We reference the access-list we created earlier.

Now the traffic we selected with this access-list will not be NATted through the ASA.

Let’s do the same for the branch site:

access-list Inside_nat0_outbound extended permit ip 192.168.0.0 255.255.255.0 10.0.0.0 255.255.255.0
nat (Inside) 0 access-list Inside_nat0_outbound

Note that we again changed the traffic selection to be mirrored to the main site, as we are now going the other way.

3. [Transform-sets]
——————–
This is where the order of things might get a bit confusing to some, as the transform-sets actually define the encryption of phase 2. And at this point we haven’t even configured phase 1 yet! I still like to adhere to this order as it won’t matter when configuring and it will hopefully make troubleshooting easier.

Like I said the transform-sets define which encryption we use in phase 2, or at the IPSec level. Both sides will negotiate the encryption levels and therefore the NEED to be the same on both locations. If you encrypt with key A, you will also need to decrypt with key A. Otherwise you won’t be able to read the message.

You can define your own sets, but the ASA comes with the most common ones predefined. Those have always sufficed to me so I would advise to use those unless you have a specific reason not to.
Again, as before, you just create the transform-sets here (or at least make sure they are present in the configuration) but they don’t do anything yet. We reference these transform-sets later when configuring the crypto map.

crypto IPSec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto IPSec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto IPSec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
crypto IPSec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac

When first looking at the commands they seemed a bit redundant to me, but note that after the part ‘crypto IPSec transform-set’ you define a name (here in caps). The defaults reference the encryption that is used. This could be anything you like, though. After that the encryption type and authentication type are specified.

 4. [Crypto map]
——————–
Now it’s time to define the parts that actually get the tunnel going and put some of the building blocks we created together. We do this with a crypto map.

I will first create the configuration items that we would use at the main site and then explain the individual items:

crypto map VPN_map 10 match address VPN_cryptomap
crypto map VPN_map 10 set peer 1.1.1.2
crypto map VPN_map 10 set transform-set ESP-AES-256-SHA

We use the command “crypto map” and then create a name. After the name comes a reference number. The reason for this number is that you can only apply one crypto map to each interface. This would be a problem if you had 2 branch offices and only one outside interface!

Cisco solved this by using these reference numbers. You use the same crypto map every time on an interface, but you can use different reference numbers per tunnel. This way you are able to setup multiple tunnels on this single interface.

Then on the first line you see the access-list we created referred to. This is where we say, if you see THAT traffic, put it into the tunnel.

Second, we define the peer. This is the other side of the tunnel, so in this case the WAN IP address of the branch office.

Third you tell the ASA which type of encryption you are going to use at IPSec level. We reference the NAME of the transform-set defined in the previous step.

When you have your crypto map defined it still won’t do anything until it is applied to an interface. Make sure you apply it to the interface closest to the other side of the tunnel, in our case the outside interface:

crypto map VPN_map interface outside

You would then do the same on the branch office, but obviously with the WAN IP address of the main office as it’s peer:

crypto map VPN_map 10 match address VPN_cryptomap
crypto map VPN_map 10 set peer 1.1.1.1
crypto map VPN_map 10 set transform-set ESP-AES-256-SHA
crypto map VPN_map1 interface

5. [Isakmp policy]
——————–
Now that we have the phase 2 part covered, where the actual IPSec tunnel is built, we first need to provide for a secure layer to get management traffic through. This is Isakmp or phase 1.

To get a management layer (security association) going the ASA’s need policies defined. They go top down through these policies until they find one that they agree on. If they don’t phase 1 and therefore the complete tunnel, won’t come up. Since both sides need to agree we need to create at least one policy and it needs to be the same on both sides. Let’s look at the configuration as it should be on both sides and go through it:

crypto isakmp policy 10 authentication pre-share
crypto isakmp policy 10 encryption aes-256
crypto isakmp policy 10 hash sha
crypto isakmp policy 10 group 5
crypto isakmp policy 10 lifetime 86400

You begin each line with the “crypto isakmp policy” command and create a reference number. The lower the number, the higher it will be in the config, the sooner it will be tried for setting up a tunnel. Usually you would put the most secure at the top, as it has preference.

If it can’t agree on that level of security it will go one less secure and so on.

The first line configures the means of authentication of the tunnel. You can use either a pre-shared key or a certificate. Pre-shared keys are the easiest to implement, certificate are easiest to manage in large environments. I won’t go into details of both; I chose pre-shared keys for our tunnel here for ease of explanation.

Next we define the encryption and authentication mechanisms. This looks a lot like the transform-set, however that is used for encrypting at IPSec level. We are now defining encryption at the security association level, which is created BEFORE IPSec will be setup. Once the SA’s are in place they will be used to be able to securely setup an IPSec connection.

Then we find the command ‘group 5’, which references to Diffie-Hellmann group 5. The working of Diffie-Hellmann is beyond the scope of this document, but in short it’s a secure way to get secure information (keys) over an insecure connection.

Finally the lifetime of the SA’s in seconds. After the lifetime has expired, the keys will be recalculated. The tunnel is not affected.

When you are done with configuring enable isakmp on the interface on which the ASA should be able to build a tunnel:

crypto isakmp enable Outside

This too needs to be set on both ASA’s.

 6. [Tunnel-group]
——————–
Now that we have our phase 1 and 2 configured we can use ‘tunnel-groups’ to configure specific options for the tunnel. In site to site tunnels I would advise using the IP address of the peer as the group-name. I have seen problems in the past where a different name had been used.

tunnel-group 1.1.1.2 type ipsec-l2l
tunnel-group 1.1.1.2 IPSec-attributes
pre-shared-key testkey

In the first command we tell the ASA we are creating an IPSec tunnel.

In the second we create something that we referenced earlier: the pre-shared key. You define it here and reference it in the crypto isakmp policy. Make sure that the key is the same on both ASA’s!

I would also advise to use a stronger key then the one I use here, as it is basically a password into your network.

7. [Wrap-up]
——————–
And there you have it! You have created your site to site tunnel!

Now go to a client on either one of the locations and start a ping, remote desktop session or open a web site. The first try might fail, but don’t get discouraged. When the first packet arrives at the ASA it will start setting up the tunnel, which can take a few seconds. Then try again and you should now be able to reach all pc’s, printers and servers on both sides of the tunnel.

For general troubleshooting you can use the following commands:

show crypto isakmp sa
show crypto Ipsec sa

They will show you if a tunnel is setup at either phase 1 (SA) or phase 2 (IPSec) respectively.

I know this guide isn’t as extensive as it could be and there are hundreds of different ways to setup and use VPN connections. However, I hope this document has helped you either get started or get a basic understanding of VPN’s, what they do and how to configure them.