Automatic connected virtual private network

A virtual private network (VPN) tunnel is established that extends from a source spoke to a destination spoke in a hub-and-spoke enterprise network. Prior to establishing the VPN tunnel, packets are sent from the source spoke to the destination spoke through the hub network. In this manner, packets are not dropped while the VPN tunnel is being set up. The VPN tunnel is established by querying a server for the network address of a destination router in the destination spoke, then setting up the VPN tunnel using a secure communication protocol. An extension to the Internet Key Exchange (IKE) protocol is used to obtain the private network address of the destination router during setup of the VPN tunnel. A forwarding table is updated after the VPN tunnel is established to reroute the packets through the new VPN tunnel.

TECHNICAL FIELD

Principles of the invention relate to computer networks and, more particularly, to virtual private networks (VPNs) established between computer networks.

BACKGROUND

A computer network is a collection of interconnected computing devices that exchange data and share resources. In a packet-based network, such as the Internet, the computing devices communicate data by dividing the data into small blocks called packets. The packets are individually routed across the network from a source device to a destination device. The destination device extracts the data from the packets and assembles the data into its original form. Dividing the data into packets enables the source device to resend only those individual packets that may be lost during transmission.

A private network may include a number of devices, such as computers, owned or administered by a single enterprise. These devices may be grouped into a number of site networks, which in turn may be geographically distributed over a wide area. Each site network may include one or more local area networks (LANs). With the advent of Virtual Private Network (VPN) technology, enterprises can now securely share data between site networks over a public network, such as the Internet.

A VPN may be configured in a “hub-and-spokes” topology. In a hub-and-spokes network, one site network is the hub, while other site networks are the spokes. This configuration passes all data through the central hub site network; isolating the spoke site networks, and allowing communication between devices within different spoke site networks only through the hub site network. For example, the hub site network may be the network at the headquarters of the enterprise, while the spoke site networks are typically networks at geographically distributed branch offices, sales offices, manufacturing or distribution facilities, or other remote site of the enterprise.

In some instances the remote sites may establish a spoke-to-spoke VPN tunnel to allow computing devices within the remote sites to securely handle time-sensitive communications, such as Voice over Internet Protocol (VoIP) or video conferencing, between the sites through the Internet or another public network infrastructure. A number of communication protocols have been developed for establishing a VPN tunnel. In general, these protocols allow network devices to establish the VPN tunnel as one or more secure data flows across the public network infrastructure. For example, Internet Protocol Security (IPSec) protocols and Secure Sockets Layer (SSL) protocols make use of cryptographic technology to establish network “tunnels.” These tunnels allow packets conforming to other network protocols, such as Internet Protocol (IP) packets, to be encapsulated within encrypted packet streams flowing between the sites.

One approach to spoke-to-spoke VPN communications is to maintain a permanent full mesh VPN connection. However, the cost of this approach may be prohibitive. Another option is to establish a spoke-to-spoke VPN tunnel manually whenever a VPN tunnel is needed. However, this option may consume many resources and may induce lengthy delays prior to establishment of the spoke-to-spoke VPN tunnel. An example of automatically setting up a VPN tunnel on demand, known as dynamic VPN, operates by first running a routing protocol, such as Open Shortest Path First (OSPF) or Enhanced Interior Gateway Routing Protocol (EIGRP) on all gateway routers to learn the private IP address of a destination gateway to which an originating gateway is trying to dynamically connect. Routing tables are updated with the VPN route, and packets are sent over this route. Next, the originating gateway queries a Next Hop Resolution Protocol (NHRP) server to obtain the gateway's public IP address using NHRP's private/public IP mapping functionality. Only after the public and private IP addresses are obtained does the originating gateway router use IPSec to set up the VPN tunnel between the spokes. In the meantime, packets are dropped until the VPN tunnel is set up between the spokes, making this method less desirable for time-sensitive communications. Moreover, this method requires three distinct steps, and also requires usage of routing protocols on the gateway routers of the remote sites to learn the private IP addresses.

SUMMARY

In general, principles of the invention relate to techniques for automatically connecting a spoke-to-spoke Virtual Private Network (VPN) tunnel using a secure communication protocol such as the Internet Protocol Security (IPSec) protocol. In particular, techniques are described for establishing a spoke-to-spoke VPN tunnel without requiring usage of a routing protocol at a spoke site to learn the private IP address of a gateway router associated with another spoke site. These techniques may provide better scalability. In the case of a large enterprise, the feature of not requiring usage of a routing protocol at the spoke sites may simplify network maintenance.

A source personal computer (PC) in a source spoke network begins transmission of time-sensitive communication packets to a destination PC in a destination spoke network of a hub-and-spoke VPN. A source gateway router at the edge of the source spoke network receives the packets and initiates automatic setup of a spoke-to-spoke VPN tunnel for transmitting the packets to the destination spoke network. As described herein, the source gateway router queries a server, such as a Next Hop Resolution Protocol (NHRP) server, for a public IP address of the destination gateway router. Before the source gateway router has completed establishing the spoke-to-spoke VPN tunnel, the source gateway router sends traffic through pre-existing default routes through the hub network. As a result, packets are not dropped while the spoke-to-spoke VPN tunnel is being established. The source gateway router thereafter establishes the spoke-to-spoke VPN tunnel using the IPSec protocol. Upon establishing the spoke-to-spoke VPN tunnel, the source gateway router injects the corresponding route between the spokes by updating its forwarding table, thereby causing the traffic to be automatically rerouted through the VPN tunnel established between the spokes.

In one embodiment, a method comprises obtaining a public network address associated with a destination spoke network of a virtual private network (VPN), establishing a VPN tunnel between a source spoke network of the VPN and the destination spoke network, determining a private network address associated with the destination spoke network of the VPN while establishing the VPN tunnel, and after establishing the VPN tunnel, updating a forwarding table to forward packets between the source spoke network and the destination spoke network.

In another embodiment, a device comprises a control unit that obtains a public network address associated with a destination spoke network of a virtual private network (VPN) and establishes a VPN tunnel between a source spoke network of the VPN and the destination spoke network, a forwarding table maintained by the control unit, and a secure communication protocol executed by the control unit that establishes a VPN tunnel to the destination spoke network, wherein the control unit determines a private network address associated with the destination spoke network of the VPN when establishing the VPN tunnel with the secure communication protocol.

In another embodiment, a system comprises a source spoke network of a virtual private network (VPN) and a destination spoke network of the VPN, wherein the source spoke network includes a source router that automatically establishes a spoke-to-spoke VPN tunnel between the source spoke network and the destination spoke network by using a security protocol to learn a private network address of a gateway associated with the destination spoke network.

In a further embodiment, a computer-readable medium comprises instructions for causing a device to obtain a public network address associated with a destination spoke network of a virtual private network (VPN), establish a VPN tunnel between a source spoke network of the VPN and the destination spoke network, determine a private network address associated with the destination spoke network of the VPN while establishing the VPN tunnel, and after establishing the VPN tunnel, update a forwarding table to forward packets between the source spoke network and the destination spoke network.

DETAILED DESCRIPTION

FIG. 1is a block diagram illustrating an example enterprise network environment8in which customer edge (CE) routers20A-20B (collectively, “CE routers20”) automatically establish spoke-to-spoke virtual private network (VPN) tunnels in accordance with the principles of the invention. In the illustrated example ofFIG. 1, enterprise network environment8is a large enterprise network comprising hub network12and spoke networks10A-10D (collectively, “spoke networks10”). For example, spoke networks10may be networks for enterprise branch offices located in geographically separated sites. Although illustrated for ease of description with one hub network12and four spoke networks10, enterprise network environment8may have a plurality of hub networks12and spoke networks10.

In the example ofFIG. 1, provider edge router22is an edge router of hub network12, and provides connectivity for spoke networks10A and10B. In particular, provider edge router22is logically coupled to customer edge routers20A and20B via hub-to-spoke VPN tunnels14A and14B, respectively.

Although not shown, hub network12and spoke networks10may be separate by one or more public networks, such as the Internet. For example, hub network12may be coupled to one or more networks administered by other providers, and may thus form part of a large-scale public network infrastructure, e.g., the Internet. Similarly, spoke networks10may be viewed as edge networks of the Internet. The enterprise may provide computing devices within spoke networks10with access to the Internet via customer edge routers, and may allow computing devices within one of spoke networks10to communicate with computing devices in the other of spoke networks10over the Internet. Hub network12may include a variety of network devices, such as routers, switches, or servers.

Similarly, each of spoke networks10may include one or more computing devices, such as personal computers, laptop computers, handheld computers, workstations, servers, switches, or printers. For example, spoke networks10A and10B contain personal computers (PCs)16A and16B (collectively “PCs16”). A personal computer, such as PC16A of spoke network10A, may initiate transmission of time-sensitive communications to a personal computer located in a different spoke network, such as PC16B of spoke network10B. For example, PC16A may want to do Voice over Internet Protocol (VoIP) or video conferencing with PC16B. To provide secure communication, CE router20A may automatically set up a spoke-to-spoke VPN tunnel18between spoke network10A and spoke network10B. In many cases, CE router20A may elect to use a route for spoke-to-spoke VPN tunnel18that does not go through hub network12.

As will be described in further detail below, in response to time-sensitive communications or other traffic, CE router20A may set up spoke-to-spoke VPN tunnel18by exchanging a public and a private network address (e.g., IP address) of spoke10B via the hub. To obtain the public IP address of a gateway router for the destination PC16B, e.g., CE router20B, CE router20A queries a Next Hop Resolution Protocol (NHRP) server (not shown) for the public IP address of CE router20B. The NHRP server may be located at any point along the route to PC16B through hub network12. For example, the NHRP server may be located on PE router22. As another example, the NHRP server may be located on CE router20B.

Before spoke-to-spoke VPN tunnel18is established, traffic CE router20A sends the time-sensitive traffic to spoke10B through default routes through hub network12, i.e., via VPN tunnels14. As a result, packets associated with the time-sensitive traffic are not dropped while spoke-to-spoke VPN tunnel18is being established while the private and public IP addresses of a gateway router for PC16B are learned. CE router20A thereafter establishes spoke-to-spoke VPN tunnel18using a secure communication protocol such as the Internet Protocol Security (IPSec) protocol. Upon establishing spoke-to-spoke VPN tunnel18, CE router20A updates a forwarding table to inject a corresponding route between spoke networks10A and10B, thereby causing traffic to be automatically rerouted through VPN tunnel18established between the spoke networks. As a result, CE router20A may automatically setup spoke-to-spoke VPN tunnel18with only two steps: (1) querying an NHRP server for a gateway router's public IP address and (2) establishing the VPN tunnel using IPSec or some other secure protocol. In this manner, time-sensitive communications may be securely transferred from PC16A to PC16B.

A remote client, e.g., a human administrator or an automated script, may access customer edge routers20to set policy data to selectively indicate what types of network traffic should trigger establishment of a spoke-to-spoke VPN tunnel18. As a result, customer edge routers20may easily initiate setup of spoke-to-spoke VPNs. In this manner, the techniques may reduce or eliminate the need for administrators to manually configure customer edge routers20in order to achieve communications through spoke-to-spoke VPN tunnels. As a result, the techniques may avoid significant administrative resources that otherwise would be necessary to manually initiate setup of spoke-to-spoke VPNs on demand.

FIG. 2is a block diagram illustrating an exemplary embodiment of a router30that automatically establishes spoke-to-spoke VPN tunnels in accordance with the principles of the invention. Router30may be a gateway router, such as CE router20A ofFIG. 1.

Routing table39describes the topology of a network, such as enterprise network environment8ofFIG. 1, and, in particular, routes through the network. Routing table39may include, for example, route data that describes various routes within a network, as well as labels that will be applied to the traffic. Router30receives routing communications from other routers, and updates routing table39to accurately reflect the topology of the network in accordance with the routing communications.

Router30generates forwarding table38based upon the routes stored within routing table39. Upon updating routing table39, control unit32regenerates forwarding table to associated destinations with specific next hops and outbound links44. Control unit32may maintain forwarding table38and routing table39in the form of one or more tables, databases, link lists, radix trees, databases, flat files, or any other data structures.

In general, when router30receives a packet via one of inbound links42, control unit32determines a destination and an associated next hop for the packet in accordance with forwarding table38and routing table39. Router30then forwards the packet on one of outbound links44based on the selected next hop. In particular, control unit32determines a next hop for each inbound packet based on forwarding information38, identifies a corresponding IFC40associated with the next hop, and relays the packet to the appropriate IFC40.

Control unit32provides an operating environment for protocols34A-34B (collectively, “protocols34”) executing within control unit32. In this example, protocols34include a Next Hop Resolution Protocol34A (“NHRP34A”) and an Internet Protocol Security protocol34B (“IPSec34B”). In general, NHRP34A is used to resolve next hops to public IP addresses by querying an NHRP server. When establishing VPN tunnel18, NHRP34A is used to identify and query an NHRP server to obtain a public network address for a gateway router associated with network spoke10B. In the example ofFIG. 1, NHRP34A identifies then queries the NHRP server for the public network address (e.g., IP address) of CE router20B.

IPSec34B is an exemplary tunneling protocol that may provide router30with authentication of remote systems and establishment of secure communications with the systems. For example, IPSec34B may provide end-to-end security between router30and a gateway router. In the exemplary embodiment ofFIG. 2, IPSec34B includes an Internet Key Exchange (IKE) module36. Control unit32may utilize IKE module36to negotiate and establish an IPSec tunnel. In particular, control unit42may invoke IKE module36to exchange cryptographic keys and other session information with the other network device. IKE module36may automatically negotiate security associations to secure packets transmitted from router30to another network.

IKE module36may be an extended version of the conventional IKE protocol that additionally exchanges private IP addresses of gateway routers at the time of the key exchange. Thus, a routing protocol is not required to obtain the private IP address of the gateway router prior to setting up a spoke-to-spoke VPN, and the usage of the routing protocol may be eliminated. As a result, the automatic setup of a spoke-to-spoke VPN tunnel (e.g., spoke-to-spoke VPN tunnel ofFIG. 1) may proceed with only two steps: querying an NHRP server for a gateway router's public IP address, and establishing the VPN tunnel using IPSec34B. During this last step, the private address of the gateway router for the destination network spoke may be automatically determined due to the extended IKE module36, and this private address may be used for updating routing table39and forwarding table38to redirect traffic through the spoke-to-spoke VPN tunnel. Although described for exemplary purposes in reference to IPSec, the principles described herein may by applied to extend any secure communication protocol that may be used to establish secure tunnels.

The architecture of router30illustrated inFIG. 2is for exemplary purposes only, and the principles of the invention are not limited to this architecture. Control unit32may operate according to executable instructions fetched from one or more computer-readable media. Examples of such media include random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), flash memory, and the like. The functions of router30may be implemented by executing the instructions of the computer-readable medium with one or more processors, discrete hardware circuitry, firmware, software executing on a programmable processor, or a combination of any of the above.

In addition, the forwarding functionality described with respect to control unit32may be distributed between control unit32and IFCs40. In such an embodiment, any combination of control unit32and one of more of IFCs40may automatically establish a spoke-to-spoke VPN tunnel in accordance with the principles of the invention described herein.

FIG. 3is a flow diagram illustrating exemplary operation of the router in accordance with the principles of the invention. For exemplary purposes, the flow diagram ofFIG. 3will be explained in reference toFIG. 1and, in particular, customer edge routers20.FIG. 3illustrates how automated establishment of a spoke-to-spoke VPN tunnel may be accomplished in two substantive steps.

Suppose PC16A in spoke network10A wants to securely send time-sensitive traffic to PC16B located in spoke network10B. CE router20A can accomplish this by setting up a spoke-to-spoke VPN tunnel18. Upon receiving time-sensitive traffic (or before receiving the traffic but in response to another event), CE router20A automatically sets up spoke-to-spoke VPN tunnel18using two main steps. First, CE router20A queries an NHRP server, asking for the public IP address of the gateway router that CE router20A associated with PC16B (48). In this case, that gateway router is CE router20B, and the NHRP server responds with the public IP address of CE router20B.

With this information, CE router20A is set to use IPSec or some other security protocol to establish the VPN tunnel18(50). CE router20A need not first determine the private IP address of CE router20B, since this information will become available while IPSec is establishing VPN tunnel18. In particular, the IKE protocol, which runs as part of the IPSec protocol, has been extended to exchange the private IP addresses for the gateway routers while it exchanges security keys for use in encrypting and decrypting packets. Thus, CE router20A need not run a routing protocol or otherwise perform an additional step to obtain the gateway's private IP address before establishing VPN tunnel18.

FIG. 4is a flow diagram illustrating exemplary operation of the router in further detail in accordance with the principles of the invention. In particular,FIG. 4illustrates in further detail operation of the router when performing the two substantive steps set forth inFIG. 3. In general, steps52-56correspond to step48ofFIG. 3, while steps58-64correspond to step50. For exemplary purposes, the flow diagram ofFIG. 4will be explained in reference toFIG. 1and, in particular, customer edge routers20.

Suppose PC16A in spoke network10A wants to securely send time-sensitive traffic to PC16B located in spoke network10B. CE router20A will do this by setting up a spoke-to-spoke VPN tunnel18. To set up the spoke-to-spoke VPN tunnel18, CE router20A needs to know the public IP address of CE router20B. CE router20A will send out an NHRP query to ask for the public IP address of CE router20B. To do this, however, CE router20A must first determine where the NHRP query should be sent. Initially, CE router20A queries its own routing table to determine a next hop associated with PC16B (52). In particular, CE router20A looks up the IP address of PC16B in its routing table to identify a next hop associated with routes to PC16B. In the case ofFIG. 1, CE router20A determines that PC16B lies behind provider edge (PE) router22. CE router20A issues an NHRP query for the NHRP server to PE router22, in order to obtain the public IP address of CE router20B (54).

When PE router22receives the NHRP query, if PE router22does not know the public IP address of CE router20B, PE router22will similarly do a look-up in the routing table of PE router22, and will forward the NHRP query to the next hop on the route to PC16B. InFIG. 1, the next hop is CE router20B. Thus, PE router22forwards the NHRP query to CE router20B. CE router20B receives the NHRP query, and knows that PC16B is located behind CE router20B. CE router20B sends its own public IP address to CE router20A. In this manner, CE router20A obtains the public IP address of CE router20B, to be used in setting up VPN tunnel18. This method makes use of the fact that the NHRP query will follow the route path and eventually reach the serving gateway router of the traffic destination.

While CE router20A is performing the steps above, CE router20A also sends the traffic from PC16A to PC16B through a default route through the hub via VPN tunnels14A and14B (56). This route may be less direct and, consequently, slower than VPN tunnel18will be when the VPN tunnel is established, but usage of the default route will ensure that packets are not dropped while VPN tunnel18is being established. CE router20A continues to send the packets through the hub network until after the private IP address is determined and VPN tunnel18is ultimately established.

Once CE router20A has received the public IP address of CE router20B, CE router20A uses IPSec or some other security protocol to establish spoke-to-spoke VPN tunnel18from spoke network10A to spoke network10B (58). While VPN tunnel18is being established, IKE module36(FIG. 2) of IPSec protocol34B exchanges keys for encryption and decryption. In addition, the extend version of IKE module36also exchanges the private IP addresses for the gateways of the spoke networks10A and10B (60). In this manner, CE router20A obtains the private IP address for CE router20B without performing additional steps or usage of additional protocols.

After the private IP address is learned and VPN tunnel18is established, CE router20A updates forwarding table38to redirect the traffic through VPN tunnel18(62). CE router20A then sends the traffic to CE router20B via the established VPN tunnel18(64). In this manner, time-sensitive communications may be securely transferred from PC16A to PC16B. Moreover, setup of VPN tunnel18can be completed without use of a routing protocol for determining the private IP address of CE router20B. Further, packets are not lost during the process because the forwarding table is updated to reflect the VPN route only after VPN tunnel18is actually established and able to carry traffic.