Configuring Tunnel EndPoint Discovery

20 Mar

Configuring Tunnel EndPoint Discovery
The ability to automate as much of the configuration and maintenance of IPSec VPNs as possible is important for administrators who are challenged to minimize their administrative and operations costs and at the same time layer sophisticated IP services, such as IPSec. One IPSec enhancement that helps simplify VPN configuration is Tunnel EndPoint Discovery (TED), which was available beginning in Cisco IOS software version 12.0(5)T. Tunnel EndPoint Discovery allows IPSec to scale to large networks by reducing multiple encryption schemes, reducing the setup time, and allowing for simple configurations on participating peer routers. Each IPSec−enabled router has a simple configuration that defines the local network that the router is protecting and the IPSec transforms that are required. Tunnel

EndPoint Discovery is recommended for use with networks in which the IPSec peers are not always predetermined.

To understand how Tunnel EndPoint Discovery works, I will use Figure 6.9 as an example for the rest of this discussion. In Figure 6.9, Host A behind Router A attempts to establish a session with Host B behind Router B. If Router A has not initiated encryption services before with Router B (meaning no security association is set up), it compares the IP address of the destination host, Host B in this case, to an access list that defines a range of IP addresses that determine which network devices are members of the IPSec VPN group. This is accomplished via the use of a permit statement within the access list. Upon receipt of the packet from Host A that is destined to Host B, Router A drops the packet and then sends a TED probe packet to Router B. Upon receipt, Router B drops the TED packet and sends a TED reply packet to Router A with its own IP address in the payload of the packet. When Router A receives the TED reply packet, it initiates dynamic Internet Key Exchange (IKE), which enables Router A to establish a secure network session.

Figure 6.9: Tunnel EndPoint Discovery
To configure Tunnel EndPoint Discovery, use the following commands:

1.Configure the IKE process as explained in “Configuring IPSec using Pre−Shared Keys” earlier in this chapter.

2.Use the following command to create a dynamic crypto map entry:

crypto dynamic−map <dynamic−map−name> <seq−num>

Use of this command places you in dynamic crypto map configuration command mode.

3.To specify which transform sets can be used with the dynamic crypto map entry, use the following command:

set transform set <transform−set−name1>−
<transform−set−name2….transform−set−name6>

List multiple transform sets in order of priority with the highest−priority transform set listed first.

4.In dynamic crypto map configuration mode, use this command to specify an extended access list for a crypto map entry that matches packets that should be protected by encryption:

match address <access−list number | name>

Use the following command to add one or more dynamic crypto map sets into a crypto map set via crypto map entries that reference the dynamic crypto map sets:

crypto map <map−name> <seq−num> ipsec−isakmp −
dynamic <dynamic−map−name> discover

The discover parameter defined on the dynamic crypto map enables peer discovery.

6.Apply the crypto map to an interface using the crypto map<map−name> command. The map name specified with this command is the name of the crypto map that was created in Step 5.

Listing 6.23 and Listing 6.24 display the configuration needed to enable TED on both Router A and Router B (use Figure 6.9 as a reference).

Listing 6.23: Tunnel EndPoint Discovery configuration of Router A.

hostname Router−A
!
username ipsec privilege 15 password 0 ipsec
ip subnet−zero
ip tcp synwait−time 10
no ip domain−lookup
!
crypto isakmp policy 10
authentication pre−share
group 2
hash sha
!
crypto isakmp key aandbkey address 0.0.0.0
!
crypto ipsec transform−set discovery esp−des esp−md5−hmac
!
crypto dynamic−map discovery−map 10
set transform−set ted−transforms
match address 100
!
crypto map tunnelend 10 ipsec−isakmp dynamic discovery−map −
discover
!
interface Ethernet1
ip address 192.168.11.1 255.255.255.0
no ip directed−broadcast
!
interface Serial0/0
ip address 192.168.10.1 255.255.255.0
no ip directed−broadcast
crypto map tunnelend
!
ip classless ip route 0.0.0.0 0.0.0.0 192.168.10.2
no ip http server
!
access−list 100 permit ip 192.168.11.0 0.0.0.255 192.168.12.0 −
0.0.0.255
access−list 100 permit icmp 192.168.11.0 0.0.0.255 192.168.12.0 −
0.0.0.255
!
line con 0
login local
transport input none
line aux 0
line vty 0 4
login local

Listing 6.24: Tunnel EndPoint Discovery configuration of Router B.

hostname Router−B
!
username ipsec privilege 15 password 0 ipsec
ip subnet−zero
ip tcp synwait−time 10
no ip domain−lookup
!
crypto isakmp policy 10
authentication pre−share
group 2
hash sha
!
crypto isakmp key aandbkey address 0.0.0.0
!
crypto ipsec transform−set discovery esp−des esp−md5−hmac
!
crypto dynamic−map discovery−map 10
set transform−set discovery
match address 110
!
crypto map tunnelend 10 ipsec−isakmp dynamic discovery−map −
discover
!
interface Ethernet1/0
ip address 192.168.12.1 255.255.255.0
no ip directed−broadcast
!
interface Serial0/0
ip address 192.168.10.2 255.255.255.0
no ip directed−broadcast
crypto map tunnelend
!
ip classless ip route 0.0.0.0 0.0.0.0 192.168.10.1
no ip http server
!
access−list 100 permit ip 192.168.12.0 0.0.0.255 192.168.11.0 −
0.0.0.255
access−list 100 permit icmp 192.168.12.0 0.0.0.255 192.168.11.0 –
0.0.0.255
!
line con 0
login local
transport input none
line aux 0
line vty 0 4
login local

After Host A behind Router A attempts to initiate a connection to Host B behind Router B, dynamic IPSec security association takes place. Because Router A has not initiated encryption services before with Router B (meaning no security association is set up), Router A compares the IP address of the destination host, Host B in this case, against access list 100, which defines a range of IP addresses that determine which network devices are members of the IPSec VPN group. Upon receipt of the packet from Host A that is destined to Host B, Router A drops the packet and then sends a TED probe packet to Router B. Upon receipt, Router B drops the TED packet and sends a
TED reply packet to Router A with its own IP address in the payload of the packet. When Router A receives the TED reply packet, it initiates dynamic Internet Key Exchange (IKE), which enables Router A to establish a secure network session. You can verify that a secure session has been set up by issuing the debug crypto ipsec, debug crypto isakmp, and debug crypto engine commands on Router A and having Host A attempt to connect Host B. Listing 6.25 displays the complete output of the Tunnel EndPoint Discovery process.

Listing 6.25: Complete Tunnel EndPoint process for Router A.

: IPSEC(tunnel discover request):,
(key eng. msg.) src= 192.168.11.1, dest= 192.168.12.1,
src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4),
dest_proxy= 192.168.10.1/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= esp−des esp−md5−hmac,
lifedur= 3600s and 4608000kb,
spi= 0×0(0), conn_id= 0, keysize= 0, flags= 0×4004
dest=Ethernet0/0:192.168.10.2
: ISAKMP: received ke message (1/1)
: ISAKMP: GOT A PEER DISCOVERY MESSAGE FROM THE SA MANAGER!!!
: src = 192.168.11.1 to 192.168.12.1, protocol 3, transform 2,
hmac 1
: proxy source is 192.168.11.0/255.255.255.0 and my address
(not used now) is 192.168.10.1
: ISAKMP: local port 500, remote port 500
: ISAKMP (2): ID payload
next−payload : 5
type : 1
protocol : 17
port : 500
length : 8
: ISAKMP (2): Total payload length: 12
: 1st ID is 192.168.10.1
: 2nd ID is 192.168.11.0 /255.255.255.0
: ISAKMP (0:2): beginning peer discovery exchange
: ISAKMP (2): sending packet to 192.168.12.1 (I) PEER_DISCOVERY
via Ethernet0/0:192.168.10.2
: ISAKMP (2): received packet from 192.168.10.2(I)PEER_DISCOVERY
: ISAKMP (0:2): processing vendor id payload
: ISAKMP (0:2): speaking to another IOS box!
: ISAKMP (0:2): processing ID payload. message ID = 0
: ISAKMP (0:2): processing ID payload. message ID = −1594735024
: ISAKMP (2): ID_IPV4_ADDR_SUBNET dst 192.168.12.0/255.255.255.0
prot 0 port 0
: ISAKMP (2): received response to my peer discovery probe!
: ISAKMP: initiating IKE to 192.168.10.2 in response to probe.
: ISAKMP: local port 500, remote port 500
: ISAKMP (0:2): created new SA after peer−discovery
with 192.168.10.2
: ISAKMP (3): sending packet to 192.168.10.2 (I) MM_NO_STATE
: ISAKMP (0:2): deleting SA reason “delete_me flag/throw” state
(I) PEER_DISCOVERY (peer 192.168.12.1) input queue 0
: ISAKMP (3): received packet from 192.168.10.2 (I) MM_NO_STATE
: ISAKMP (0:3): processing SA payload. message ID = 0
: ISAKMP (0:3): Checking ISAKMP transform 1 against priority
10 policy
: ISAKMP: encryption DES−CBC
: ISAKMP: hash SHA
: ISAKMP: default group 2
: ISAKMP: auth pre−share
: ISAKMP (0:3): atts are acceptable. Next payload is 0
: CryptoEngine0: generate alg parameter
: CRYPTO_ENGINE: Dh Phase 1 status: 0
: CRYPTO_ENGINE: Dh Phase 1 status: 0
: ISAKMP (0:3): SA is doing pre−shared key authentication
: ISAKMP (3): SA is doing pre−shared key authentication
using id type ID_IPV4_ADDR
: ISAKMP (3): sending packet to 192.168.10.2 (I) MM_SA_SETUP
: ISAKMP (3): received packet from 192.168.10.2 (I) MM_SA_SETUP
: ISAKMP (0:3): processing KE payload. message ID = 0
: CryptoEngine0: generate alg parameter

: ISAKMP (0:3): processing NONCE payload. message ID = 0
: CryptoEngine0: create ISAKMP SKEYID for conn id 3
: ISAKMP (0:3): SKEYID state generated
: ISAKMP (0:3): processing vendor id payload
: ISAKMP (0:3): speaking to another IOS box!
: ISAKMP (3): ID payload
next−payload : 8
type : 1
protocol : 17
port : 500
length : 8
: ISAKMP (3): Total payload length: 12
: CryptoEngine0: generate hmac context for conn id 3
: ISAKMP (3): sending packet to 192.168.10.2 (I) MM_KEY_EXCH
: ISAKMP (0:2): purging SA.
: CryptoEngine0: delete connection 2
: ISAKMP (3): received packet from 192.168.10.2 (I) MM_KEY_EXCH
: ISAKMP (0:3): processing ID payload. message ID = 0
: ISAKMP (0:3): processing HASH payload. message ID = 0
: CryptoEngine0: generate hmac context for conn id 3
: ISAKMP (0:3): SA has been authenticated with 192.168.10.2
: ISAKMP (0:3): beginning Quick Mode exchange, M−ID of 699308944
: ISAKMP (0:3): asking for 1 spis from ipsec
: ISAKMP (0:3): had to get SPI’s from ipsec.
: CryptoEngine0: clear dh number for conn id 1
: IPSEC(key_engine): got a queue event…
: IPSEC(spi_response): getting spi 560995998 for SA
from 192.168.10.2 to 192.168.10.1 for prot 3
: ISAKMP: received ke message (2/1)
: CryptoEngine0: generate hmac context for conn id 3
: ISAKMP (3): sending packet to 192.168.10.2 (I) QM_IDLE
: ISAKMP (3): received packet from 192.168.10.2 (I) QM_IDLE
: CryptoEngine0: generate hmac context for conn id 3
: ISAKMP (0:3): processing SA payload. message ID = 699308944
: ISAKMP (0:3): Checking IPSec proposal 1
: ISAKMP: transform 1, ESP_DES
: ISAKMP: attributes in transform:
: ISAKMP: encaps is 1
: ISAKMP: SA life type in seconds
: ISAKMP: SA life duration (basic) of 3600
: ISAKMP: SA life type in kilobytes
: ISAKMP: SA life duration (VPI) of 0×0 0×46 0×50 0×0
: ISAKMP: authenticator is HMAC−MD5 : validate proposal 0
: ISAKMP (0:3): atts are acceptable.
: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) dest= 192.168.10.2, src= 192.168.10.1,
dest_proxy= 192.168.12.0/255.255.255.0/0/0 (type=4),
src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp−des esp−md5−hmac,
lifedur= 0s and 0kb,
spi= 0×0(0), conn_id= 0, keysize= 0, flags= 0×4
: validate proposal request 0
: ISAKMP (0:3): processing NONCE payload. message ID = 699308944
: ISAKMP (0:3): processing ID payload. message ID = 699308944
: ISAKMP (0:3): processing ID payload. message ID = 699308944
: CryptoEngine0: generate hmac context for conn id 3
: ipsec allocate flow 0
: ipsec allocate flow 0
: ISAKMP (0:3): Creating IPSec SAs
: inbound SA from 192.168.10.2 to 192.168.10.1
(proxy 192.168.12.0 to 192.168.11.0)
: has spi 560995998 and conn_id 2000 and flags 4
: lifetime of 3600 seconds

: lifetime of 4608000 kilobytes
: outbound SA from 192.168.10.1 to 192.168.10.2
(proxy 192.168.11.0 to 192.168.12.0)
: has spi 104538836 and conn_id 2001 and flags 4
: lifetime of 3600 seconds : lifetime of 4608000 kilobytes
: ISAKMP (3): sending packet to 192.168.10.2 (I) QM_IDLE
: ISAKMP (0:3): deleting node 699308944 error FALSE reason “”
: IPSEC(key_engine): got a queue event…
: IPSEC(initialize_sas):,
(key eng. msg.) dest= 192.168.10.1, src= 192.168.10.2,
dest_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4),
src_proxy= 192.168.12.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp−des esp−md5−hmac,
lifedur= 3600s and 4608000kb,
spi= 0×21701E9E(560995998), conn_id= 2000,
keysize= 0, flags= 0×4
: IPSEC(initialize_sas):,
(key eng. msg.) src= 192.168.10.1, dest= 192.168.10.2,
src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4),
dest_proxy= 192.168.12.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp−des esp−md5−hmac,
lifedur= 3600s and 4608000kb,
spi= 0×63B22D4(104538836), conn_id= 2001, keysize= 0,
flags= 0×4
: IPSEC(create_sa): sa created,
(sa) sa_dest= 192.168.10.1, sa_prot= 50,
sa_spi= 0×21701E9E(560995998),
sa_trans= esp−des esp−md5−hmac, sa_conn_id= 2000
: IPSEC(create_sa): sa created,
(sa) sa_dest= 192.168.10.2, sa_prot= 50,
sa_spi= 0×63B22D4(104538836),
sa_trans= esp−des esp−md5−hmac, sa_conn_id= 2001
Router−A#


Random Posts

No comments yet

Leave a Reply

You must be logged in to post a comment.