␡
- "Do I Know This Already?" Quiz
- Authentication, Authorization, and Accounting
- Remote Authentication Dial-In User Service
- Terminal Access Controller Access Control System Plus
- Encryption Technology Overview
- Certificate Enrollment Protocol
- Extensible Authentication Protocol, Protected EAP, and Temporal Key Integrity Protocol
- Virtual Private Dial-Up Networks (VPDN)
- Foundation Summary
- Q & A
- Scenario: Configuring Cisco Routers for IPSec
- Scenario Answers
< Back
Page 12 of 12
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter is from the book
Scenario Answers
Scenario Solutions
- The following debug output advises the network administrator of the problem:
22:58:55: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 131.108.255.1 failed it s sanity check or is malformed....
During the IKE negotiation, the router reports a message that identifies the fault as the share password. R2 is configured with the password, CCIe (should match R1's preshared password set to CCIE). See Example 4-17, and code line 7.
Changing the IKE password to CCIE with the IOS command crypto isakmp key CCIE address 131.108.255.1, the following debug output confirms the IPSec connections by pinging from R2 Ethernet 0/0 IP address to R1 Ethernet 0/0 IP address:
R2#ping Protocol [ip]: Target IP address: 131.108.100.1 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 131.108.200.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.108.100.1, timeout is 2 seconds: 23:12:21: CryptoEngine0: generate alg parameter 23:12:21: CRYPTO_ENGINE: Dh phase 1 status: 0 23:12:21: CRYPTO_ENGINE: Dh phase 1 status: 0 23:12:21: CryptoEngine0: generate alg parameter 23:12:21: CryptoEngine0: create ISAKMP SKEYID for conn id 1 23:12:21: CryptoEngine0: generate hmac context for conn id 1 23:12:21: CryptoEngine0: generate hmac context for conn id 1 23:12:21: CryptoEngine0: generate hmac context for conn id 1 23:12:21: CryptoEngine0: clear dh number for conn id 1 23:12:22: CryptoEngine0: generate hmac context for conn id 1 23:12:22: validate proposal 0 23:12:22: validate proposal request 0 23:12:22: CryptoEngine0: generate hmac context for conn id 1.!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 12/13/16 ms R2#
The first ping packet fails because the IPSec tunnel has not yet been created. Then, the IPSec tunnel is successfully brought up between R1 and R2.
- Access-list 100 on both routers defines the IP subnets that need to be encrypted between R1 and R2. Packets flowing between subnets 131.108.100.0/24 and 131.108.200.0/24 will be encrypted.
R1's ACL is as follows:
access-list 100 permit ip 131.108.100.0 0.0.0.255 131.108.200.0 0.0.0.255
R2's ACL is as follows:
access-list 100 permit ip 131.108.200.0 0.0.0.255 131.108.100.0 0.0.0.255 - The show crypto map IOS command displays the remote peer address and the transform set. The previous displays are taken from R1 because the remote peer address is displayed as 131.108.255.2 (R2's serial 0/0 IP address).
- Yes, because IPSec has nothing to do with routing IP data, IPSec will encrypt only data as configured. R1 has a remote entry to the network residing on R2, and R2 has a remote entry to the network residing on R1. Traffic between A and C and B and C will not be encrypted; only traffic between A and B will be encrypted.
Here is a sample ping request from R2 to R1 and Host A and Host C:
R2>ping 131.108.100.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.108.100.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms R2> R2>ping 131.108.101.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.108.101.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms R2> R2>ping 131.108.100.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.108.100.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms R2> R2>ping 131.108.101.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.108.105.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms
- Because the source network is located on R1, access-list 100 on R1 needs to be modified, remembering that, by default, an implicit deny is defined on ACL 100. Network 131.108.101.0/24 is only permitted to encrypt traffic to the static IP address 131.108.200.5, hence the ACL line required on R1 becomes the following:
access-list 100 permit ip 131.108.100.5 0.0.0.0 131.108.200.0 0.0.0.255 access-list 100 permit ip 131.108.101.0 0.0.0.255 131.108.200.5 0.0.0.0
or:
access-list 100 permit ip 131.108.100.5 0.0.0.0 131.108.200.0 0.0.0.255 access-list 100 permit ip 131.108.101.0 0.0.0.255 host 131.108.200.5
On R2 the access list becomes:
access-list 100 permit ip 131.108.200.0 0.0.0.255 131.108.101.0 0.0.0.255 access-list 100 permit ip 131.108.200.5 0.0.0.0 131.108.100.0 0.0.0.255
IP routing is already configured and working. IPSec will ensure only that IP data is encrypted.
< Back
Page 12 of 12