Configuring IPSec VPNs

Because simple misconfiguration is the cause of many issues that arise with IPSec VPNs, this section discusses basic configuration of both site-to-site and remote access VPNs. This section also assumes that IKE is being used for SA negotiation.

Note that it is also possible to manually configure IPSec session keys on IPSec peers. This method of configuration, however, is comparatively rare, and is, therefore, not discussed further in this chapter.

Similarly, although there are three methods of peer authentication during IKE negotiation, only preshared keys and digital signatures are widely used. The third method, encrypted nonces, is also not discussed further in this section.

Configuring a Site-to-Site IPSec VPN

Configuration of the site-to-site VPN varies according to whether preshared or digital certificates are used for peer authentication. This section is therefore divided into two parts:

• Configuring site-to-site IPSec VPNs with preshared keys

• Configuring site-to-site IPSec VPNs with digital certificates

Configuring Site-to-Site IPSec VPNs with Preshared Keys

Configuration of site-to-site IPSec VPNs using preshared keys involves six basic steps on each peer:

The sections that follow cover these steps in more detail.

Step 1: Configure the Preshared Key

When using preshared key authentication, the first step is to configure the preshared key. The preshared key should consist of an alphanumeric string and must be identical on the peer routers. The preshared key for a particular peer is configured using the crypto isakmp key key address peer_address command.

Example 8-1 shows the configuration of a preshared key.

Example 8-1. Configuration of the ISAKMP Preshared Key

								crypto isakmp key cisco address 172.16.6.2
							

In Example 8-1, the preshared key cisco is configured for peer 172.16.6.2. This particular choice of preshared key is not secure and is used only for illustrative purposes.

The address keyword is used in conjunction with the (phase 1) identity set using the crypto isakmp identity {address | hostname} command. The default identity is address, so in this case, there is no need to configure this command.

Note that the crypto isakmp identity command should be configured with the default (IP) address option when using preshared keys.

Step 2: Configure IKE Policies

Once preshared key has been defined, the next step is to configure IKE (ISAKMP) policies. An IKE policy defines the cryptographic parameters to be used during IKE negotiation. Included in the IKE policy are the encryption algorithm, the hash algorithm, the Diffie-Hellman group, and the method of authentication. IKE policies are specified using the crypto isakmp policy priority command.

The parameters used with the IKE policy are then configured using the authentication, encryption, group, hash, and lifetime commands. These commands are used to specify the authentication method, encryption algorithm, Diffie-Hellman group, hash algorithm, and IKE SA lifetime, respectively.

Example 8-2 shows a sample IKE policy configuration.

Example 8-2. Sample IKE Policy

								crypto isakmp policy 10
								hash md5
								authentication pre-share
							

Example 8-2 configures an IKE policy with a priority of 10. The encryption algorithm is DES, the Diffie-Hellman group is 1, the hash algorithm is MD5, the authentication method is preshared keys, and the IKE SA lifetime is 86,400 seconds. The encryption algorithm, Diffie-Hellman group, and lifetime are not shown in Example 8-2 because they are the defaults.

Table 8-2 shows the encryption algorithms, hash algorithms, Diffie-Hellman groups, methods of authentication, and lifetimes that can be configured for IKE policies on Cisco routers.

Note that multiple IKE policies can be configured with differing priorities ranging from 1 to 10,000. The policy with the highest priority has the lowest number. IKE policy negotiation between peers begins with the highest priority policy.

Also, when IKE is enabled, a default policy with a priority of 65535 is created. This policy contains the default values indicated in Table 8-2.

Step 3: Configure the IPSec Transform Set

The IPSec transform set defines the cryptographic parameters to be used by the IPSec SAs negotiated during IKE phase 2 (quick mode).

The parameters defined in the IPSec transform set are the security and compression protocols, hash algorithm, and encryption algorithm.

The transform set is configured using the crypto transform-set transform_set_name transform1 [transform2] [transform3] [transform4] command.

Example 8-3 shows a sample configuration of a IPSec transform set.

Example 8-3. Sample IPSec Transform Set

								crypto ipsec transform-set mjlnettrans esp-des esp-md5-hmac
							

In Example 8-3, an IPSec transform set called mjlnettrans is created that specifies two transforms:

• ESP with encryption using the DES algorithm

• Authentication using the MD5-HMAC algorithm

Table 8-3 lists the security and compression protocols, as well as hash and encryption algorithms (transforms), that can be specified in an IPSec transform set.

The IPSec mode can also be specified when configuring the transform set. The two available modes are as follows:

• Tunnel mode— The default mode, which is used to provide protection for user traffic transiting the router.

• Transport mode— This mode is used to provide protection for traffic in an end system to end system configuration.

You might think that tunnel mode is the only mode required when configuring IPSec on a router. This is usually the case, but when configuring protection for a Generic Routing Encapsulation (GRE), Layer Two Forwarding (L2F), or Layer Two Tunneling Protocol (L2TP) tunnel sourced by the router itself, transport mode protection can be used.

The IPSec mode is configured using the mode {tunnel | transport} command.

Transport mode could be configured for transform set mjlnettrans (from Example 8-3) as shown in Example 8-4.

Example 8-4. Configuring Transport Mode Protection

								crypto ipsec transform-set mjlnettrans esp-des esp-md5-hmac
								mode transport
							

Step 4: Configure the Crypto Access List

Configuration of the crypto access list comes next. The crypto access list defines traffic that is protected by the IPSec transforms specified in the transform set.

The crypto access list must be an extended IP access list, as shown Example 8-5.

Example 8-5. Configuring the Crypto Access List

								access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
							

In Example 8-5, access list 101 specifies that IP traffic between networks 10.1.1.0/24 at the local site and 10.2.2.0/24 at the remote site is protected.

The crypto access list not only defines what outbound traffic is protected, but also what inbound traffic should be protected. If traffic arrives that matches the crypto access list, but is not protected in the manner defined by the transform set, the traffic is dropped.

IPSec natively protects unicast IP traffic, but if you want to protect multiprotocol or multicast traffic, you have to configure a GRE over IPSec tunnel.

If you configure a GRE tunnel, the crypto access list should be in the following form: access-list number permit gre host gre_tunnel_source_address host gre_tunnel_destination_address.

Step 5: Configure the Crypto Map

The crypto map brings together the specification of peer address, transform set, and crypto access list. In doing so, it defines what traffic will be protected and how it will be protected when sent and received from an IPSec peer.

Additionally, you can specify within the crypto map that the local router should negotiate perfect forward secrecy (PFS) with the peer when establishing new IPSec SAs.

The crypto map is configured using the crypto map map_name sequence_number ipsec-isakmp command.

The peer address, transform set, and crypto access list associated with the crypto map are configured using the set peer peer_address, set transform-set transform_set_name, and match address access_list_number commands, respectively.

PFS can optionally be configured using the set pfs {group 1 | group 2} command.

Example 8-6 shows a sample crypto map.

Example 8-6. Sample Crypto Map

								crypto map mjlnetmap 10 ipsec-isakmp
								set peer 172.16.6.2
								set transform-set mjlnettrans
								match address 101
							

Example 8-6 defines a crypto map called mjlnetmap. An entry with sequence number 10 is configured that specifies the transform set (mjlnettrans) and crypto access list (101) that will be used with IPSec peer 172.16.6.2.

If the local router is going to establish IPSec SAs with multiple peers on a given interface, you can configure multiple entries (sequence numbers) in the crypto map, one for each peer.

If you are unsure of the addresses or parameters to be used with peers that might connect, you can configure a dynamic crypto map.

Step 6: Apply the Crypto Map to the External Interfaces

Once you have configured the crypto map, the next step is to apply it to an interface or interfaces. The interfaces to which the crypto map should be applied are the external interfaces—that is, the interfaces on which you expect to send and receive IPSec protected traffic to and from the remote peer.

The crypto map is applied to the interfaces using the crypto map crypto_map_name command.

In Example 8-7, crypto map mjlnetmap is applied to interface serial 4/0 using the crypto map crypto_map_name command.

Example 8-7. Applying the Crypto Map to the Interface

								interface Serial4/0
								crypto map mjlnetmap
							

Note that only one crypto map can be applied to an interface.

Configuring Site-to-Site IPSec VPNs with Preshared Keys: Sample Configuration

Example 8-8 shows a complete sample configuration of an IPSec VPN router using preshared keys.

Example 8-8. IPSec VPN Router Configuration Using Preshared Keys

Tokyo#show running-config
Building configuration...
Current configuration : 2046 bytes
!
version 12.2
service nagle
no service pad
service tcp-keepalives-in
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname Tokyo
!
logging buffered 16384 debugging
enable secret 5 $1$t0rF$AbPOBhIDFsyUUjfBr002y/
!
clock timezone GMT 0
ip subnet-zero
no ip source-route
ip cef
!
no ip domain-lookup
!
no ip bootp server
ip ssh time-out 120
ip ssh authentication-retries 3
!
! Configure the IKE Policy
crypto isakmp policy 10
 hash md5
 authentication pre-share
!
! Configure the pre-shared key
crypto isakmp key cisco address 172.16.6.2
!
!! Configure the IPSec transform set
crypto ipsec transform-set mjlnettrans esp-des esp-md5-hmac
!
! Configure the crypto map
crypto map mjlnetmap 10 ipsec-isakmp
 set peer 172.16.6.2
 set transform-set mjlnettrans
 match address 101
!
interface FastEthernet0/0
 ip address 10.1.1.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
 no keepalive
 duplex half
 no cdp enable
!
! Apply the crypto map to the external interface
interface Serial4/0
 ip address 172.16.5.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
 no fair-queue
 no cdp enable
 crypto map mjlnetmap
!
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.5.5
no ip http server
ip pim bidir-enable
!
logging trap debugging
!
! Configure the crypto access list
access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
!
line con 0
 password 7 05080F1C2243
 login
line aux 0
line vty 0 4
 password 7 121A0C041104
 login
!
!
end
Tokyo#

Configuring Site-to-Site IPSec VPNs with Digital Certificates

Configuration of site-to-site IPSec VPNs using digital certificates is very similar to that for preshared keys and involves 12 basic steps on each peer:

The sections that follow discuss Steps 1 to 8 in more detail. Steps 9 to 12 are identical to Steps 3 to 6 in the previous section (“Configuring Site-to-Site IPSec VPNs with Preshared Keys”), and so are not discussed further here. See the previous section for a discussion of these steps.

Step 1: Configure the Router's Clock and Time Zone

The first step when configuring IPSec VPNs using digital certificates is to set the clock and time zone. Use the clock set and clock timezone commands to set the router's clock and time zone, respectively.

An alternative to setting the clock manually on each router is to configure the Network Time Protocol (NTP). Using NTP is a good idea if your routers do not have hardware clocks because their clock settings will be lost in the event of a reboot. See Cisco.com for more details about configuring NTP.

Step 2: Configure the Router's Hostname and Domain Name

The next step is to configure the router's hostname and domain name using the hostname and ip domain-name commands.

Ensure that you follow the guidelines in RFC 952. These guidelines are summarized as follows:

• The hostname should be no more than 24 characters long.

• The name may include the A–Z, 0–9, minus sign (-), and period (.) characters.

• Periods should be used only to delimit parts of the domain name.

• No blank spaces should be included in the name.

• The first character should be an alpha character (a–z, A–Z).

• The last character should not be a period (.) or a minus sign(-).

The hostname is concatenated with the domain name configured on the router to produce an FQDN.

Step 3: Ensure That the Certificate Server Is Reachable

Ensure that the CA server's name is either mapped locally using the ip host name IP_address command or is resolvable via DNS.

Also ensure that the CA server is reachable using the ping command.

Step 4: Generate the Router's RSA Key Pairs

Next you must generate the router's RSA key pairs. RSA keys are generated using the crypto key generate rsa [usage-keys | general-keys] command. By default, this command will generate a single pair of general usage keys. These keys can then be used for both encryption and signing.

If you want to use separate key pairs for encryption and signatures, specify the usage-keys keyword.

In Example 8-9, general-purpose keys with a modulus of 1024 bits are generated on the router. Note that Cisco recommends a minimum modulus of 1024 bits.

Example 8-9. General-Purpose Keys Are Generated

Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#crypto key generate rsa
The name for the keys will be: Tokyo.mjlnet.com
Choose the size of the key modulus in the range of 360 to 2048 for your
  General Purpose Keys. Choosing a key modulus greater than 512 may take
  a few minutes.
How many bits in the modulus [512]: 1024
% Generating 1024 bit RSA keys ...[OK]
Tokyo(config)#

Step 5: Declare the CA

After generating the RSA keys, the next step is to declare the CA that will be used by the router.

Use the crypto ca trustpoint name command to declare the CA. Note that this command replaces the crypto ca identity command. Cisco routers support CAs from a number of vendors including Baltimore, Entrust, iPlanet, Microsoft, and Verisign.

In Example 8-10, the router is configured to communicate with a Microsoft CA called mjlnetca.

Example 8-10. Configuration for a Microsoft CA Server

								crypto ca trustpoint mjlnetca
								enrollment mode ra
								enrollment url http://mjlnetca:80/certsrv/mscep/mscep.dll
								crl optional
							

In Example 8-10, the enrollment mode ra command is used to specify that the router is communicating with a Registration Authority (RA).

The URL for the CA is then specified using the enrollment url url command. This command is mandatory. Check with your CA administrator for the correct URL.

Finally, the crl optional command is used to specify that the router should accept a peer's certificate even if the certificate revocation list (CRL) is unavailable.

Step 6: Authenticate the CA

The router now needs to authenticate the CA by obtaining its certificate.

Use the crypto ca authenticate name command to authenticate the CA server, as shown in Example 8-11.

Example 8-11. Authentication of the CA

Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#crypto ca authenticate mjlnetca
Certificate has the following attributes:
Fingerprint: 9C514FE0 A4A56F42 8612D771 6AC073FC
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
Tokyo(config)#

In Example 8-11, a CA server called mjlnetca is authenticated.

Note that a fingerprint is displayed. The CA administrator should also be able to see the fingerprint of the certificate. If the two fingerprints are the same, then you know that the certificate is valid and can be accepted.

Step 7: Enroll the Router with the CA

By enrolling the router with the CA, you obtain a certificate for each RSA key pair on the router.

Use the crypto ca enroll name command to enroll the router with the CA, as demonstrated in Example 8-12.

Example 8-12. Router Enrollment with the CA

Tokyo(config)#crypto ca enroll mjlnetca
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
   password to the CA Administrator in order to revoke your certificate.
   For security reasons your password will not be saved in the configuration.
   Please make a note of it.
Password:
Re-enter password:
% The fully-qualified domain name in the certificate will be: Tokyo.mjlnet.com
								% The subject name in the certificate will be: Tokyo.mjlnet.com
								% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The certificate request fingerprint will be displayed.
% The 'show crypto ca certificate' command will also show the fingerprint.
Tokyo(config)#    Fingerprint:  259CD7C2 C194427A 304F0670 975570F3
Tokyo(config)#

In Example 8-12, router Tokyo enrolls with CA server mjlnetca. Note that the router's FQDN (Tokyo.mjlnet.com) is included in the certificate (highlighted line 1). You can also choose to include the router's serial number and IP address in the certificate's subject name as indicated in highlighted lines 2 and 3.

Step 8: Configure the IKE Policy

When configuring the IKE policy using digital certificates, you must specify rsa-sig as the authentication method.

Example 8-13 shows a sample configuration of IKE policy when using digital certificates.

Example 8-13. IKE Policy with RSA Signature Authentication

crypto isakmp policy 10
 hash md5

In the IKE policy shown in Example 8-13, the method of authentication is RSA signatures, the encryption algorithm is DES, the Diffie-Hellman group is 1, the hash algorithm is MD5, and the lifetime is 86,400 seconds. With the exception of the hash algorithm, all of these parameters are the defaults and are therefore not shown.

That completes the configuration of site-to-site IPSec VPNs.

Configuring Remote Access VPNs with Cisco VPN Client 3.x / 4.0

Cisco routers running Cisco IOS Software Release 12.2(8)T or later can be configured to support connections from Cisco VPN Client 3.x/4.0.

There are ten steps involved in configuring support for Cisco VPN Client 3.x/4.0 (with local authentication):

The sections that follow describe these steps in greater detail.

Step 1: Configure the Local Username Database

If you are using local authentication, the first step in configuring support for Cisco VPN Client 3.x/4.0 is to configure the local username database, as demonstrated in Example 8-14.

Example 8-14. Configuration of the Local Username Database

							username nakano password cisco
						

In Example 8-14, username nakano is specified with password cisco.

The usernames and passwords specified here correspond to those that remote users have to enter during extended authentication (XAuth).

Extended authentication takes place after IKE phase 1, and it allows the user of the remote device, in addition to the device itself, to be authenticated. The device is authenticated during IKE phase 1.

Step 2: Configure AAA

The next step is the configuration of AAA, as demonstrated in Example 8-15.

Example 8-15. Configuration of AAA

							aaa new-model
							aaa authentication login mjlnetUsers local
							aaa authorization network mjlnet local
						

In Example 8-15, the aaa new-model command is used to enable AAA.

Next comes the aaa authentication login mjlnetUsers local command, which defines the authentication method list mjlnetUsers. This method list specifies that the method used for login authentication should be the local username database.

Finally, the aaa authorization network mjlnet local command defines the mjlnet method list for network authorization. This method list specifies that the method used for network authorization should be local.

Step 3: Configure the Local IP Address Pool

An IP address pool from which addresses are assigned to remote access clients is configured in Step 3.

The IP address pool is configured using the ip local pool name start_address end_address command.

Example 8-16 shows a sample IP address pool.

Example 8-16. Configuration of the IP Address Pool

							ip local pool mjlnetPool 10.2.2.1 10.2.2.253
						

In Example 8-16, IP address pool mjlnetPool is configured on the router. This pool contains IP addresses in the range 10.2.2.1–10.2.2.253.

Step 4: Configure IKE Policies

After AAA is configured, the next step is to configure the IKE policy, as demonstrated in Example 8-17.

Example 8-17. IKE Policy for Cisco VPN Client 3.x/4.0

							crypto isakmp policy 10
							hash md5
							authentication pre-share
							group 2
						

The IKE policy in Example 8-17 specifies an ISAKMP (IKE) policy with a priority of 10. This policy specifies that the authentication method is pre-share, the encryption algorithm is DES (the default), the Diffie-Hellman group is 2, the hash algorithm is MD5, and the lifetime is 86,400 seconds (the default).

For more details about parameters that can be configured in IKE policies see the section “Configuring a Site-to-Site IPSec VPN” on page 669.

Step 5: Configure the Split Tunneling Access List (Optional)

An access list that is used to enable split tunneling can now be configured. Split tunneling is used so that the remote access clients will send only traffic destined for the corporate network via the IPSec tunnel.

Example 8-18 demonstrates the configuration of the split tunneling access list.

Example 8-18. Split Tunneling Access List

							access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
						

The access list in Example 8-18 will ensure that traffic from network 10.2.2.0/24 (allocated to the clients from the local address pool) to network 10.1.1.0/24 (the corporate network) will travel over the IPSec tunnel.

Step 6: Configure the VPN Client Group Policy Profile

The group policy profile is used to specify parameters such as the preshared key used for IKE authentication and client configuration parameters. Example 8-19 shows a sample group policy profile.

Example 8-19. Sample Group Policy Profile

							crypto isakmp client configuration group mjlnetVPN
							key cisco
							dns 10.1.1.100
							wins 10.1.1.101
							pool mjlnetPool
							acl 101
						

Example 8-20 shows a group policy profile called mjlnetVPN. This profile defines the preshared key (key pre-shared-key), DNS and WINS server addresses (dns server_address, wins server_address), the IP address pool from which addresses will be assigned to remote access clients (pool pool_name, specified in Step 3), and the access list that will be used to enforce split tunneling on the clients (acl access-list_number, specified in Step 5). The DNS and WINS server addresses, as well as the assigned address from the IP address pool, are all pushed to the remote access client during mode configuration (Mode Config). These parameters are pushed to the remote access client after extended authentication (XAuth).

The group policy profile name (in this example, mjlnetVPN) and preshared key must match the name and the password specified under Group Access Information in the New Connection Entry Wizard of Cisco VPN Client 3.x, or the name and password specified under Group Authentication in the Create New VPN Connection Entry Wizard of Cisco VPN Client 4.0.

Step 7: Configure the IPSec Transform Set

The next step is the configuration of the IPSec transform set, as demonstrated in Example 8-20.

Example 8-20. IPSec Transform Set

							crypto ipsec transform-set mjlnetTrans esp-des esp-md5-hmac
						

In this example, the transform set (mjlnetTrans) specifies two transforms. These are ESP with encryption using the DES algorithm, and authentication using the MD5-HMAC algorithm.

Step 8: Configure the Dynamic Crypto Map

Step 8 is to configure the dynamic crypto map, which allows the router to negotiate SAs with remote access clients when not all parameters are known. This is essential because it is difficult or impossible to know the IP address of remote access clients when they connect to the router over the Internet.

The dynamic crypto map is created using the crypto dynamic-map name sequence_number command.

Example 8-21 shows a sample dynamic crypto map.

Example 8-21. Dynamic Crypto Map

							crypto dynamic-map mjlnetDyn 10
							set transform-set mjlnetTrans
						

In Example 8-21, the dynamic crypto map mjlnetDyn is created. The transform set mjlnetTrans (configured in Step 7) is then specified.

One other very useful command that you might want to configure with the dynamic crypto map is the reverse-route command. When used with dynamic crypto maps, this command causes static routes corresponding to IPSec SAs negotiated with remote clients to be placed into the routing table. These routes can then be redistributed into a routing protocol as required.

Step 9: Configure IKE Extended Authentication, Authorization, Client Mode Address Configuration, and a Crypto Profile for Remote Clients

The next step is to configure IKE extended authentication, authorization, client mode configuration, and a crypto profile.

Extended authentication is configured on a crypto map using the crypto map name client authentication list method_list_name command.

Authorization on the crypto map is configured using the crypto map name isakmp authorization list method_list_name command.

Client mode address configuration is specified using the crypto map name client configuration address {initiate | respond} command. The initiate keyword specifies that the router should attempt to configure an IP address for the clients. The respond keyword specifies that the router can accept requests for IP address configuration from the clients.

Finally, the crypto map name sequence_number ipsec-isakmp dynamic dynamic_map_name command is used to configure a crypto profile that provides a template used to create dynamic crypto maps.

Example 8-22 shows sample configurations of these commands.

Example 8-22. Configuration of Extended Authentication, Authorization, Client Address, and Crypto Profile

							crypto map mjlnetMap client authentication list mjlnetUsers
							crypto map mjlnetMap isakmp authorization list mjlnet
							crypto map mjlnetMap client configuration address respond
							crypto map mjlnetMap 10 ipsec-isakmp dynamic mjlnetDyn
						

In Example 8-22, extended authentication is configured using the mjlnetUsers method list (specified in Step 2), authorization is configured using method list mjlnet (specified in Step 2), client mode address configuration is specified so that the router will respond to client IP address requests, and a crypto profile is created using the dynamic crypto map created in Step 8.

Step 10: Apply the Crypto Map to the External Interface

The last step is to apply the crypto map to the external interface, as demonstrated in Example 8-23.

Example 8-23. Apply the Crypto Map to the External Interface

							interface Serial4/0
							crypto map mjlnetMap
						

In Example 8-23, the crypto map (with the name specified in Step 9) is applied to the external interface.

That completes the configuration of the router for a remote access VPN.

IPSec Remote Access VPN Gateway: Sample Configuration

Example 8-24 shows a complete sample configuration of an IPSec remote access VPN gateway.

Example 8-24. Sample IPSec Remote Access VPN Gateway Configuration

Tokyo#show running-config
Building configuration...
Current configuration : 2543 bytes
!
version 12.2
service nagle
no service pad
service tcp-keepalives-in
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname Tokyo
!
logging buffered 16384 debugging
enable secret 5 $1$ABA3$Wmyspeir29lZ9Enrp.rr50
!
! Configure the local username database
username koenji password 7 121A0C041104
username nakano password 7 05080F1C2243
username shinjuku password 7 110A1016141D
username roppongi password 7 05080F1C2243
clock timezone GMT 0
!
! Configure AAA
aaa new-model
aaa authentication login mjlnetUsers local
aaa authorization network mjlnet local
aaa session-id common
ip subnet-zero
no ip source-route
ip cef
!
!
!
no ip bootp server
!
! Configure IKE policies
crypto isakmp policy 10
 hash md5
 authentication pre-share
 group 2
!
! Configure the VPN Client group policy profile
crypto isakmp client configuration group mjlnetVPN
 key cisco
 dns 10.1.1.100
 wins 10.1.1.101
 pool mjlnetPool
 acl 101
!
!
! Configure the IPSec transform set
crypto ipsec transform-set mjlnetTrans esp-des esp-md5-hmac
!
! Configure the dynamic crypto map
crypto dynamic-map mjlnetDyn 10
 set transform-set mjlnetTrans
!
! Configure IKE extended authentication, client mode address configuration, and a crypto 
profile for remote clients
crypto map mjlnetMap client authentication list mjlnetUsers
crypto map mjlnetMap isakmp authorization list mjlnet
crypto map mjlnetMap client configuration address respond
crypto map mjlnetMap 10 ipsec-isakmp dynamic mjlnetDyn
!
interface FastEthernet0/0
 ip address 10.1.1.254 255.255.255.0
 no ip redirects
 no ip proxy-arp
 duplex half
 no cdp enable
!
! Apply the crypto map to the external interface
interface Serial4/0
 ip address 172.16.5.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
 serial restart_delay 0
 no fair-queue
 no cdp enable
 crypto map mjlnetMap
!
!
! Configure the local IP address pool
ip local pool mjlnetPool 10.2.2.1 10.2.2.253
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.5.5
no ip http server
ip pim bidir-enable
!
logging trap debugging
!
! Configure the split tunneling access list
access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
no cdp run
!
line con 0
line aux 0
line vty 0 4
end
Tokyo#
						

Maximum Transmission Unit (MTU) Issues with IPSec

When using IPSec tunnels to transport traffic between sites, or from a remote access client to a security gateway, you should be aware of Maximum Transmission Unit (MTU) issues that may result.

IPSec adds significant overhead to the regular IP packet. The size of the overhead depends on the security protocol, the choice of tunnel or transport mode, encryption padding, and the size of the authentication data field, with padding and authentication data being of variable size.

A good rough starting point when calculating IPSec tunnel mode overhead is 60 bytes (with ESP encryption and authentication). If you are using transport mode, you save 20 bytes because a new IP header is not prepended to the packet (compare the figures from 8-3 to 8-6). If you are using GRE over IPSec to transport multiprotocol and multicast packets, this will add a further 24 bytes (GRE header [4 bytes] + additional IP header [20 bytes]).

There are two issues with large IPSec packets:

• Large IPSec packets may become fragmented if the packet size is greater than the outgoing interface MTU of any of the routers in the path between IPSec peers, and the Don't Fragment (DF) bit is not set in the IP header of IPSec packets (the DF bit setting is copied from the original IP packet). Fragments cause high overhead on the receiving IPSec router, because it reassembles them.

• If Path MTU Discovery (PMTUD), a mechanism used to detect the smallest link MTU over a network, is broken, then large packets may be dropped if the Don't Fragment (DF) bit is set in the packet header. When a router in the path between the IPSec peers needs to fragment a large IPSec packet because it is larger than the router's outgoing interface MTU, and the DF bit in the IP header of the tunnel packet is set, the router should send an Internet Control Message Protocol unreachable message (ICMP message type 3, code 4) back to the IPSec router that sent the IPSec packet. This message should specify that fragmentation is required but that the DF bit is set; at this point, the IPSec router should decrease the size of packets that it sends. PMTUD breaks if a router in the path between IPSec peers does not send ICMP unreachable messages when it should, or a firewall blocks these messages.

There are a number of ways around these issues:

• If possible, you should reconfigure firewalls to permit ICMP unreachable (type 3, code 4) messages.

• You can configure IPSec routers to perform fragmentation of large IP packets before encrypting them. If packets are fragmented before encryption, then reassembly is performed on the end host (destination of the protected IP packet), and not on the remote IPSec router.

• If you are using a GRE tunnel with IPSec, you can configure the tunnel path-mtu-discovery command on the GRE tunnel interface. This enables PMTUD support on the GRE tunnel interface.

• If you are using a GRE tunnel with IPSec, you can also configure the router to dynamically reduce the Maximum Segment Size (MSS) value in TCP SYN packets sent over the tunnel using the ip tcp adjust-mss commands. This will cause end hosts to send smaller TCP segments (and IP packets).

• As a last resort, you can clear the DF bit on packets before they are sent over the IPSec tunnel. Clearing the DF bit allows IPSec packets to be fragmented and can therefore cause high CPU overhead on the remote IPSec peer as packets are reassembled.