Tunnel Endpoint Discovery

Tunnel Endpoint Discovery (TED) is a logical extension to the dynamic crypto maps that allows an endpoint to dynamically, proactively discover a previously unknown peer. TED therefore allows peers to proactively initiate the negotiation of IPSec tunnels with unknown peers when the local peer is brought online.

TED accomplishes these tasks by sending TED probes out of the local VPN endpoint's crypto-enabled interfaces. The remote peer does not need to have TED configured in order to be discovered by inbound TED probes. As we will see when configuring TED, VPN devices that receive TED probes on interfaces that do not have TED configured can successfully negotiate a dynamically initiated tunnel using TED. We will use Figure 12-4 to demonstrate how a TED-enabled router can dynamically determine the remote endpoint.

Figure 12-4. Using TED to Initiate IPSec VPN Tunnel Negotiation

In the extranet topology configured in Figure 12-4, a host on the extranet partner site wants to communicate with a server on the central campus. The extranet partner's local VPN endpoint, however, does not know the peer address with which to build a tunnel. Instead, TED has been enabled on the extranet partner router so that the peer address can be dynamically discovered through the following steps (also referenced in Figure 12-4):

1.	A host wants to communicate securely with a resource on the opposite end of a VPN connection (to be created) and begins sending packets to the destination.
2.	The host's local VPN gateway receives the packet, then checks its source and destination IP (s=111.1.1.100, d=201.1.1.100) against the crypto-protected address space defined in its configured crypto ACLs.
3.	If the VPN gateway finds a match against its configured crypto ACLs, it sends a TED probe with the original source (111.1.1.100/24) and destination (201.1.1.100/24) IP addresses in the payload out of its crypto-enabled interfaces.
4.	The router or VPN appliance on the remote side receives the TED probe, decapsulates it, and checks the source and destination address in the payload of the TED probe against its own crypto-protected address space in its own locally configured crypto ACLs.
5.	If the remote endpoint finds a match in Step 4, it sends a TED reply containing layer 3 addressing information of the destination to the original source (s=201.1.1.100/24, d=111.1.1.100/24).
6.	The local endpoint at the extranet site checks the TED reply against its crypto-protected address space in its crypto ACLs for a potential match.
7.	If the address space in the TED reply matches those in the local endpoint's crypto ACLs, the local crypto endpoint initiates IKE negotiation with the peer that sent the TED reply.

In the next section, we will explore TED configuration and verification steps required. The configurations will follow the steps and dynamic crypto map procedures outlined previously in this chapter.

TED Configuration and Verification

In this configuration, we will discuss enabling TED as well as the appropriate steps to take when verifying IPSec VPN operation using TED. As illustrated in Example 12-8, TED is only allowed on dynamic crypto maps. As a result, the only two prerequisites for the use of TED are the use of ISAKMP (TED is not supported with manual IPSec keying) and the use of dynamic crypto maps.

Example 12-8. Enabling Tunnel Endpoint Discovery

AS1-7304A# ! !#<--When referencing a dynamic crypto map in a static crypto map entry, !specifying the "discover" keyword enables the transmission of TED probes !on physical interfaces where the static crypto map is applied.--> crypto map extranet 10 ipsec-isakmp dynamic extranet-dyn discover

Enabling TED in this fashion allows AS1-7304A to initiate IPSec tunnel negotiation with AS113-3745A. Without TED, traffic tagged as IPSec on AS1-7304A would be dropped if a remote peer had not initiated a VPN connection previously. With TED, however, this IPSec-tagged traffic would initiate ISAKMP Phase 1 negotiation to the remote peer, and traffic would therefore not be dropped.