VPN Concentrator Routing

The VPN 3000 Concentrator needs to be enabled to route packets to other networks. To perform this function, you can configure the VPN Concentrator to use static routes, as well as utilize the RIP and OSPF routing protocols. When configured, the routable networks populate the concentrators routing table. The routing process in the VPN 3000 Concentrator first uses routes learned dynamically, then static routes, followed by the default route. You set the IP routing configurations at the Configuration | System | IP Routing screen, as depicted in Figure 6.5.

Figure 6.5. IP Routing screen.

Static Routes and Default Gateway

With static routes, you manually specify the destination networks that the concentrator needs to reach. When you add the route, you need to specify the network identifier, subnet mask, and the metric (lower is preferred) for the destination network. You must also specify the next-hop address or interface that is to forward packets destined for the network.

Similar to static routes, a default gateway route is a manual entry that specifies where to send data when there is not an exact match in the routing table. This gateway of last resort is a very common configuration because the concentrator sends VPN traffic to the Internet out its public interface. For this very reason, you predominantly assign the IP default gateway to be your Internet perimeter router located on your public network. In the configuration, you also can define a tunnel default gateway. This is utilized when you have a parallel firewall or router performing NAT between the public and private networks.

RIP and OSPF Dynamic Routing Protocols

Dynamic routing protocols, in the forms of RIP and OSPF, can also be enabled for automatic network discovery. General OSPF parameters can be configured for the VPN 3000 Concentrator on the IP Routing screens; however, the majority of the parameters for RIP and OSPF are actually configured on the interface screens. On each interface, you can enable the routing protocol and configure the particulars in accordance to the concentrator's routing function in the network. If necessary, you can filter OSPF and RIP by assigning or modifying filters on the interface to forward or drop RIP and/or OSPF.

DHCP Relay

When the VPN concentrator receives a broadcast DHCP request from a VPN client on its public or external interface, DHCP relay allows the concentrator to forward that request as a broadcast destined for UDP port 67 on its private interface or to a specified server IP address. When a DHCP server responds to the DHCP request, it uses UDP port 68 to forward the requested information to the concentrator, which, in turn, forwards the information to the requesting client. This function is similar to the Cisco IOS router's IP helper-address command. If this function is enabled, it is important to apply the DHCP In and DHCP Out rules to the interface filters.

VPN Concentrator Redundancy

In certain enterprise networks, it may be necessary to provide resiliency and fault tolerance for devices supporting VPN connectivity. These types of environments rely heavily on uninterrupted connectivity to the central office so that productivity is not affected. If any failures occur in the VPN infrastructure, the network has to recover quickly from these setbacks to minimize downtime.

Recall from Chapter 3, "Cisco VPN 3000 Concentrator Hardware," that the VPN Concentrator can provide redundancy when running in parallel with another concentrator or a group of concentrators. You can accomplish this redundancy by using a protocol called Virtual Router Redundancy Protocol (VRRP), which is similar to Cisco's HSRP protocol for router redundancy. To function properly, all the concentrators must have their private interfaces in the same subnet, and their public interfaces must be in the same subnet (different from the private), as illustrated in Figure 6.6. One of the concentrators in the group is configured as a master concentrator whose purpose is to process all requests sent to the VRRP group virtual IP address and VRRP virtual MAC address(00:00:5e:00:01:XX where XX is the group ID in hex). If the master concentrator should fail, the backup concentrators would detect the lack of VRRP messages from the master on both interfaces. At that point, the first backup concentrator would take over the active role and process requests being sent to the group virtual IP address.

Figure 6.6. Concentrator redundancy design.

For example, when Mr. Ed configures his client to connect to the VPN Concentrator configured in Figure 6.6 and Figure 6.7, he uses the public virtual IP address (192.168.1.100) as the connection destination. If the master concentrator fails, a backup concentrator would resume any LAN-to-LAN sessions that the master concentrator was maintaining. However, remote access sessions do not automatically switch over; thus, these sessions need to be reconnected. With that being said, if Mr. Ed is connected when the master concentrator fails, he needs to reconnect the client because he is using a remote access session. In these instances, there is a positive aspect: Because the backup concentrator will also use the same virtual IP address, there is no reconfiguration necessary on the client when reconnecting.

Figure 6.7. Concentrator redundancy configuration screen.

When concentrator redundancy is enabled, you cannot additionally have load balancing enabled. In addition, when the master concentrator fails, LAN-to-LAN sessions are automatically recovered by the backup concentrator; however, client remote access tunnels need to reconnect.

To configure concentrator redundancy, the Configuration | System| IP Routing | Redundancy screen depicted in Figure 6.7 contains all the parameters you need. You must enable VRRP (disabled by default) and assign the concentrators to the same group ID. If you want to secure this functionality, you may also assign a password, which also must match on all concentrators in the redundant design. In the Role drop-down box, you can select whether the concentrator will be the master or one of the five possible backup concentrators. The default hello interval is 1 second for VRRP, but you can change that interval to any length up to 255 seconds (not recommended). If you are the master concentrator, the public and private (and external, if applicable) group addresses default to the IP addresses of those interfaces. With that being said, you cannot use DHCP for IP address assignment on the concentrator's interfaces. On each backup concentrator, you must change the group IP address to coincide with the master's group IP addresses.

Reverse Route Injection

When the VPN Concentrator connects to other networks, downstream devices running RIP and OSPF on the concentrator's private network do not know how to get to those newly connected networks or hosts. With reverse route injection (RRI), connecting devices can inject their internal addresses into the concentrator's routing table so they can be distributed to other routing devices through the use of the RIP or OSPF routing protocols. In cases where the connection is a LAN-to-LAN tunnel or Cisco VPN 3002 Hardware Client operating in Network Extension mode, the internal networks are injected into the concentrator's RIP or OSPF updates. Connecting VPN clients insert their assigned internal IP addresses to the concentrator's routing table.

Be sure to remember that RRI relies on RIP and OSPF to advertise the injected routes in the concentrator's routing table.

Please note that the injected remote addresses and networks are not actually injected into the routing process by the remote devices. Only the VPN 3000 Concentrator with RRI enabled can perform this function. The remote devices determine which networks are capable of being injected.

As illustrated in Figure 6.8, Router A is learning via RIP about networks that have been injected into the concentrator. The LAN-to-LAN concentrator and VPN 3002 Hardware Client running in Network Extension mode injected their entire private network. The VPN 3002 Hardware Client running in Client mode and the Unity Client are injecting their assigned tunnel address from the concentrator's address pool.

Figure 6.8. Reverse route injection scenario.

To configure RRI, all configurations take place on the VPN Concentrator at the Configuration | System | IP Routing | Reverse Route Injection page. Figure 6.9 displays the two configuration options presented on the RRI screen. These options are to enable RRI for software clients and/or enable RRI for Cisco VPN 3002 Hardware Clients connecting in Network Extension mode (LAN-to-LAN RRI is explained later). The Hold Down Routes section enables you to define the networks to be injected manually so they will always be inserted into the routing table. You can type the network and subnet mask in the N.N.N.N/S.S.S.S notation, as displayed in Figure 6.9. Furthermore, you can have the concentrator automatically assign networks in the address assignment pool by clicking on the Generate Hold Down Routes button. For example, the configuration in Figure 6.9 demonstrates that the hold down route 10.1.1.112/255.255.255.240 was automatically added when the Generate Hold Down Routes button was pressed. This particular range was added to the address table because the assignable address pool for clients is 10.1.1.113 10.1.1.127.

Figure 6.9. Reverse route injection configuration screen.

Keep in mind for the exam that the VPN Concentrator can run Client RRI and Network Extension RRI. Client RRI entails adding assigned internal tunnel IP addresses into the concentrator's routing table from connecting Cisco VPN software clients and VPN 3002 Hardware Clients running in Client mode. Network Extension RRI adds the private networks behind a VPN 3002 Hardware Client running in Network Extension mode to the concentrator's routing table.