-
Using Management Center for VPN Routers 1.3
-
Preface
-
Introduction
-
Getting Started with Router MC
-
Router MC Scenarios
-
Working with Activities
-
Managing Devices
-
Configuring VPN Settings
-
Configuring an IOS Firewall on your VPN Router
-
Defining IKE Policies
-
Defining VPN Tunnel Policies
-
Configuring Translation Rules
-
Working with Building Blocks
-
Uploading Device Configurations
-
Deploying Configurations
-
Viewing Reports
-
Router MC Administration
-
Troubleshooting
-
Router MC Operating Prerequisites
-
Router MC User Permissions
-
Table Of Contents
Working With General VPN Settings
Understanding Failover and Routing
How Does Router MC Implement GRE?
Understanding GRE Configuration for Dynamically Addressed Spokes
Configuring Failover and Routing Policies
Prerequisites for Configuring and Deploying GRE
Important Notes about Configuring GRE
Configuring GRE for Spokes With Dynamic IP Addresses
Understanding Packet Fragmentation
Defining Fragmentation Settings (VPN)
Specifying a Hub's Inside Interfaces
Specifying a Hub's Internal Networks
Defining Catalyst VPN Services Module Settings
Specifying a Spoke's Inside Interfaces
Specifying a Spoke's Internal Networks
Specifying a Spoke's VPN Interface
Specifying a Spoke's Hub Assignment
Defining NAT Traversal Settings
Entering Additional CLI Commands (Beginning and Ending Commands)
Configuring VPN Settings
VPN settings provide a framework for network behavior and policy implementation.
Settings are defined under Configuration > Settings and include the following:
•
General VPN settings, in which you define failover and routing and fragmentation policies. See Working With General VPN Settings.
•
•
•
•
Working With General VPN Settings
General VPN settings apply to both hubs and spokes, unlike hub settings, which are specific to hubs, and spoke settings, which are specific to spokes.
Access general VPN settings by selecting Configuration > Settings > General VPN.
General VPN settings include:
•
•
Understanding Failover and Routing
IPSec failover provides VPN tunnel resiliency by rolling tunnel connections seamlessly to a failover (backup) hub if the active hub in a hub-and-spoke configuration becomes unavailable for any reason.
For failover and routing in your VPN hierarchy, you can use either IKE keepalive or IPSec with GRE. You also have the option to configure Dynamic Multipoint VPN (DMVPN) and GRE for devices with dynamic IP addresses.
Note
You can define multiple failover and routing policies within your Router MC object hierarchy, but only one failover and routing policy applies per device. For example, you could define IKE keepalive for failover on Global, and GRE on a specific device group. The GRE policy would override the IKE keepalive policy for that device group and all its descendants.
If you create, update, or remove a failover and routing policy, all the devices configured with that failover and routing policy must be deployed together.
Note
The following topics provide information about each failover and routing method:
•
•
•
•
For procedures for configuring failover and routing policies, see Configuring Failover and Routing Policies.
Understanding IKE Keepalive
With IKE keepalive, the tunnel peers exchange messages that demonstrate they are available to send and receive data in the tunnel. Keepalive messages transmit at set intervals, and any disruption in that interval results in the creation of a new tunnel, using a backup device.
Devices that rely on IKE keepalive for resiliency transmit their keepalive messages regardless of whether they are exchanging other types of information. These keepalive messages can therefore create a small but additional demand on your network.
A variation on IKE keepalive called keepalive dead-peer detection (DPD) sends keepalive messages only between peer devices that are not already exchanging other types of data. DPD is used on devices that support it.
See Configuring IKE Keepalive for the procedure for configuring IKE keepalive.
Understanding GRE
GRE is a tunneling protocol that can encapsulate different protocol packet types (such as AppleTalk, IPX, or multicast/broadcast) inside encrypted IP packets, allowing IPSec security to apply in non-IP environments.
For VPN resilience, a spoke must be configured with two GRE tunnels, one to the primary hub and the other to the backup hub. Both GRE tunnels are secured with IPSec: each one has its own IKE SA and a pair of IPSec SAs. An associated routing protocol, either EIGRP or OSPF, automates the failover mechanism, transferring to the backup tunnel if virtual link loss is detected.
Advantages of IPSec Tunneling with GRE
The main advantages of IPSec tunneling with GRE are:
•
•
•
•
Disadvantages of IPSec Tunneling with GRE
GRE does not support the use of dynamic cryptographic tunnels.
Using GRE With Frame Relay
Most of the same advantages and disadvantages apply to generic routing encapsulation (GRE) over frame relay as apply to GRE without frame relay.
Router MC supports a frame relay topology in which each hub acts only as a VPN endpoint, and each spoke acts as both a VPN endpoint and a frame relay endpoint. There must be a device in the hub subnet that acts as the second frame relay endpoint and is positioned before the VPN endpoint at the hub.
See Configuring GRE for the procedure for configuring GRE.
How Does Router MC Implement GRE?
Router MC implements a double Interior Gateway Protocol (IGP) solution for GRE. An IGP refers to a group of devices that receive routing updates from one another by means of a routing protocol, either EIGRP or OSPF. Each "routing group" is identified by a logical number. For general routing purposes, the interfaces on the routers in your networks belong to an IGP. Router MC does not manage this existing IGP. Rather, it adds an additional IGP that is dedicated for IPSec and GRE secured communication. This additional IGP is known as the secured IGP. The existing IGP (unsecured IGP), is used for routing traffic that does not require encryption.
When a GRE tunnel is established, a virtual interface is configured on each peering device. These virtual interfaces are the endpoints of the GRE tunnel. Each virtual interface is unique and is assigned with its own crypto map. The GRE tunnel interface has an IP address (inside tunnel IP address) which is taken from a loopback interface that Router MC creates specifically for this purpose. The GRE tunnel points to the source and destination IP addresses of the physical VPN interfaces on the hub and spoke. The GRE virtual interfaces on the hub and its assigned spokes belong to the secured IGP, as do the inside interfaces you defined for the hub and spoke. Routing updates within the secured IGP are GRE encapsulated and IPSec is applied. A flow whose destination is a secured interface (according to the routing updates of the secured IGP) is directed through the GRE interface where it is GRE encapsulated and then evaluated against the crypto ACL. If it matches the crypto ACL, it is routed through the GRE and VPN tunnels.
The Router MC implementation of GRE is illustrated in Figure 1-1.
Figure 1-1 Router MC Implementation of GRE
See Configuring GRE for the procedure for configuring GRE.
Understanding GRE with DMVPN
The Dynamic Multipoint VPN (DMVPN) feature allows for better scaling of large and small IPSec Virtual Private Networks (VPNs) by combining generic routing encapsulation (GRE) tunnels, IPSecurity (IPSec) encryption, and Next Hop Resolution Protocol (NHRP).
Note
In Router MC, using DMVPN with GRE provides the following advantages:
•
When using GRE, the physical interface IP address of the spoke routers must be known when configuring the hub router because this IP address must be configured as the GRE tunnel destination address. DMVPN allows spoke routers to have dynamic external interface IP addresses, and provides robust configuration that does not have to be redeployed to the device even if the external interface IP address changes.
•
NHRP provides the capability for the spoke routers to dynamically learn the external interface IP address of the routers in the VPN network. This enables the dynamic creation of an IPsec+GRE tunnel directly between spoke routers, without having to go through a hub router, thus reducing the delay of multiple encryption and decryption actions on the hub.
•
With GRE, a tunnel is configured on the hub for each connected spoke. With GRE + DMVPN, only one tunnel is configured for all the connected spokes.
Router MC uses the Auto Update Server (AUS) to retrieve information from dynamically addressed devices. Therefore, to use the DMVPN feature, you must have the AUS installed. In the Admin tab, you must provide Router MC with the information necessary to communicate with AUS. See Defining Configuration Support Settings, page 1-3.
In addition, to successfully configure DMVPN on your devices using Router MC, certain prerequisites must be met. See Prerequisites for Working With Dynamically Addressed Devices, page A-10 for more information.
Note
See Configuring DMVPN for the procedure for configuring DMVPN.
Understanding GRE Configuration for Dynamically Addressed Spokes
When a spoke has a dynamic IP address, there is no fixed GRE tunnel source address (to be used by the GRE tunnel on the spoke side) or destination address (to be used by the GRE tunnel on the hub side). Therefore, Router MC creates additional loopback interfaces on the hub and the spoke, to be used as the GRE tunnel endpoints. You must specify a subnet from which Router MC can allocate an IP address for the loopback interfaces.
Router MC uses the Auto Update Server (AUS) to retrieve information from dynamically addressed devices. Therefore, to use this feature, you must have the AUS installed. In the Admin tab, you must provide Router MC with the information necessary to communicate with AUS. See Defining Configuration Support Settings, page 1-3.
In addition, certain prerequisites must be met before configuring dynamically addressed devices with Router MC. See Prerequisites for Working With Dynamically Addressed Devices, page A-10 for more information.
Configuring Failover and Routing Policies
The following topics provide information about configuring different types of failover and routing policies:
•
•
•
Configuring IKE Keepalive
Follow the procedure below to define IKE keepalive settings.
Before you Begin
•
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
Prerequisites for Configuring and Deploying GRE
Consider the following prerequisites before using GRE in your network:
•
•
–
–
•
•
–
–
•
•
•
In general, it is recommended that Router MC has its own network access interface, separate from the inside interfaces on the device. However, if a device does not have interfaces that can be reserved for management only, and the external interface on the device is an Ethernet interface, Router MC can be connected to the network by means of an additional Ethernet hub that is attached to the hub's external Ethernet interface.
Important Notes about Configuring GRE
•
•
•
•
Configuring GRE
Follow the procedure below to configure GRE.
Before you Begin
•
–
–
•
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
Configuring DMVPN
Follow the procedure below to configure DMVPN.
Before you Begin
•
•
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
Configuring GRE for Spokes With Dynamic IP Addresses
Follow the procedure below to configure GRE for spokes with dynamic IP addresses.
Before you Begin
•
•
•
Procedure
Step 1
Step 2
Step 3
The page refreshes to display only the fields that are relevant for GRE Dynamic IP configuration.
Step 4
Click Advanced to display additional fields (optional).
See Table 1-1 for a description of each field.
Step 5
Table 1-1 describes the elements in the Failover and Routing page.
Table 1-1 Failover and Routing: GUI Reference
Policy Type list box
Select the type of failover method you want to use. The page will refresh to display only the fields relevant for your selection.
The following policy types are available:
•
•
•
•
IKE Keepalive Elements
Keepalive Interval field
Enter the required keepalive interval in seconds. This value defines the interval between the keepalive signals that peers exchange. The default value is 10 seconds.
GRE Elements
Routing Protocol list box
Select either EIGRP or OSPF as the routing protocol. See Prerequisites for Configuring and Deploying GRE for more information.
Tunnel Interface IP field
Enter a private IP address, including the subnet mask in bits, which defines a subnet in your enterprise to be used to support the implementation of loopback for GRE. For example, 192.10.9.1/255.255.255.0. Router MC creates a loopback interface on the peering devices, with an IP address from this subnet. The loopback interfaces serve as the GRE tunnel endpoints.
Tunnel Source IP field
For GRE Dynamic IP only. Enter a private IP address, including the subnet mask in bits.
Note
Enable IP Multicast check box
Select this check box to enable multicast transmissions across your GRE tunnels. IP multicast delivers application source traffic to multiple receivers without burdening the source or the receivers, while using a minimum of network bandwidth.
When IP Multicast is enabled, you must specify a rendezvous point that acts as the meeting place for sources and receivers of multicast data.
Rendezvous Point field
This field is only editable when the IP Multicast check box is selected.
Enter the IP address of the interface that will serve as the rendezvous point (RP) for multicast transmission. Sources send their traffic to the RP. This traffic is then forwarded to receivers down a shared distribution tree.
Allow direct spoke to spoke tunnels check box
For DMVPN only. Select this check box to enable direct communication between spokes, without going through the hub.
Note
Advanced or Basic button
Click the Advanced button to display additional fields for optional advanced configuration. Router MC provides default values for all the advanced options. You can change these default values if required.
When the advanced fields are displayed, click the Basic button to display only the basic configuration fields and hide the advanced fields.
Process Number field
Router MC adds an additional Interior Gateway Protocol (IGP) that is dedicated for IPSec and GRE secured communication. An IGP refers to a group of devices that receive routing updates from one another by means of a routing protocol, either EIGRP or OSPF. Each "routing group" is identified by a logical number, the process number.
Enter a routing process number that will be used to identify the secured IGP that Router MC adds when configuring GRE. See How Does Router MC Implement GRE? for more information.
The number that you provide must be within the range specified next to the field name. The default is the lowest value in the range. This range can be changed in the Configuration Support Settings page in the Admin tab. See Defining Configuration Support Settings, page 1-3 for more information.
Delay
Specify the throughput delay for the interface, in seconds.
Hello Interval EIGRP
Specify the interval between hello packets sent on the interface, from 1 to 65535 seconds. The default is 5 seconds.
Hold Time EIGRP
Specify the number of seconds the router will wait to receive a hello message before invalidating the connection. The default hold time is 15 seconds (three times the hello interval).
Tunnel Key field
For DMVPN only. Enter a number that identifies the tunnel key. The tunnel key differentiates between different multipoint GRE (mGRE) tunnel Non Broadcast Multiple Access (NBMA) networks. All MGRE interfaces in the same NBMA network must use the same tunnel key value. If there are two mGRE interfaces on the same router, they must have different tunnel key values.
Network ID (NHRP) field
For DMVPN only. All NHRP stations within one logical NBMA network must be configured with the same network identifier. Enter a globally unique, 32-bit network identifier within the range of 1 to 4294967295.
Hold Time (NHRP) field
For DMVPN only. Enter the time in seconds that routers will keep information provided in authoritative Next Hop Resolution Protocol (NHRP) responses. The cached IP-to-NBMA (non-broadcast multi-access) address mapping entries are discarded after the hold time expires.
The default is 600 seconds.
Authentication (NHRP) field
For DMVPN only. Enter an authentication string that controls whether the source and destination NHRP stations allow intercommunication. All routers within the same network using NHRP must share the same authentication string. The string can be up to eight characters long.
Apply button
Click to apply your definitions.
Clear button
The Clear button is only present if Global is selected in the Object Selector. Click the Clear button to remove your current definitions.
Defaults button
The Defaults button is present when any object other than Global is selected in the Object Selector. Click to remove your local definitions and restore the inherited default values.
Understanding Packet Fragmentation
Fragmentation is the process of breaking a packet into smaller units when it is transmitted over a physical interface that cannot support the original size of the packet. Fragmentation is the best mechanism available for minimizing packet loss in a VPN tunnel, because it permits the transmission of secured packets that might otherwise be too large to transmit successfully. This benefit is particularly relevant when using GRE, because any packet of more than 1420 bytes will not have enough room in its header for the additional 80 bytes that the combined use of IPSec and GRE adds to the packet payload.
The transmission setting for an interface is called the maximum transmission unit (MTU), and it specifies the maximum packet size, in bytes, that the particular interface can handle. If a packet exceeds the MTU, it is either fragmented or dropped (if the DF bit is set). If the DF bit is not set and the packet is fragmented, fragmentation typically takes place after encryption. Because reassembly of an encrypted packet is more difficult, fragmentation can degrade network performance. To prevent these network performance problems, fragmentation settings in Router MC configure the device so that fragmentation occurs before encryption.
Router MC can instruct the device to handle packets that are larger than the MTU either with end-to-end MTU discovery or by setting the MTU locally on the device.
•
•
Tip
Defining Fragmentation Settings (VPN)
Configuring fragmentation involves specifying how the maximum transmission unit (MTU) will be defined: either by discovery, using ICMP messages, or by setting it locally on the device.
Before you Begin
•
Procedure
Step 1
Step 2
Step 3
•
•
Step 4
Table 1-2 describes the elements in the Fragmentation page.
Working with Hub Settings
Hub settings specify the inside interfaces and internal networks on the hubs in your VPN. Hub settings also include parameters for High Availability (HA) groups.
Access hub settings by selecting Configuration > Settings > Hub Settings.
Hub settings include:
•
•
•
•
Specifying a Hub's Inside Interfaces
A hub's inside interfaces are physical interfaces or subinterfaces on the hub that connect the hub with the hub side networks. The subnets that are directly connected to the hub's inside interfaces, with no intermediary network device, are known as "attached networks." The subnets located beyond the attached networks, that are connected to the attached networks through an intermediary router, are known as "internal networks." See Specifying a Hub's Internal Networks.
You choose which of the hub's interfaces will function as the inside interfaces.
Note
Your inside interface definitions have the following purposes in Router MC:
•
•
Note
Follow the procedure below to define hub inside interfaces.
Before you Begin
•
Procedure
Step 1
Step 2
Step 3
or
Click Show Interfaces.
The Show Interfaces dialog box appears, and lists the interfaces on the devices in the selected object that are available for selection. See Table 1-4 for a description of the elements displayed in the Show Interfaces dialog box.
Step 4
Step 5
Step 6
Step 7
Table 1-3 describes the elements in the Hub Inside Interfaces page.
Table 1-3 Hub Inside Interfaces: GUI Reference
Type list box
Select the physical interface on the device. You must use a different interface from the one that is defined as the VPN interface.
Slot list box
Select the slot on which the interface is located.
Port list box
Select the interface's physical port. If you do not select a port, Router MC will include all the interfaces of the specified type in the inside interfaces. For example, if you select Ethernet in the Type list box and do not select a port, the selected interface will be Ethernet *, where * indicates that any Ethernet interface will be included.
Subinterface field
Optionally, specify a subinterface that will function as the inside interface.
Show Interfaces button
Click to open the Show Interfaces dialog box, in which you can select from a list of available interfaces. See Table 1-4 for a description of elements displayed in the Show Interfaces dialog box.
>> button;
<< buttonClick >> to add your selections to the list of selected interfaces.
Click << to remove your selections from the list of selected interfaces.
Apply button
Click to apply your definitions.
Clear button
The Clear button is only present if Global is selected in the Object Selector. Click the Clear button to remove your current definitions.
Defaults button
The Defaults button is present when any object other than Global is selected in the Object Selector. Click to remove your local definitions and restore the inherited default values.
Table 1-4 describes the elements in the Show Interfaces dialog box.
Specifying a Hub's Internal Networks
A hub's internal networks are a group of subnets that reside behind the hub but are not directly connected to the inside interfaces on that hub. This means that there is an intermediary router located between the internal networks and the networks directly attached to the hub inside interfaces (attached networks).
Internal networks can be included in your tunnel policy filter definition to specify what traffic to secure in the IPSec tunnel. For example, you can secure all traffic between the internal networks on the hub and the internal networks on the spoke. Router MC uses your internal network specifications to create the required ACLs for the tunnel policy filter options that include the internal networks.
Procedure
Step 1
Step 2
The Hub Side Networks page appears. See Table 1-5 for a description of the elements displayed in the Hub Side Networks page.
Step 3
•
•
•
Step 4
Table 1-5 describes the elements in the Hub Side Networks page.
Table 1-5 Hub Side Networks: GUI Reference
Add a Host Network field
To add a subnet to the hub side networks, enter the IP address and subnet mask, for example, 192.10.9.0/255.255.255.0.
To add a host to the hub side networks, enter the IP address or host name.
Add Network Groups list box
Hub side networks can contain other network groups. Select an existing network group from the list and click >> to add it to the hub side networks. See Working with Network Groups, page 1-13 for more information.
>> button;
<< buttonClick >> to add the specified network/host/network group to the hub side networks.
Click << to remove the specified network/host/network group from the hub side networks.
Apply button
Click to apply your definitions and override the values inherited from a higher level object.
Clear button
The Clear button is only present if Global is selected in the Object Selector. Click the Clear button to remove your current definitions.
Defaults button
The Defaults button is present when any object other than Global is selected in the Object Selector. Click to remove your local definitions and restore the inherited default values.
Defining HA Group Settings
A High Availability (HA) group is made up of two or more hub devices that use Hot Standby Routing Protocol (HSRP) to provide transparent, automatic router failover. By sharing a virtual IP address, the hubs in the HA group present the appearance of a single virtual router or default gateway to the hosts on a LAN. One of the hubs in the HA group is always active and assumes the virtual IP address, while the others are standby hubs. The hubs in the group watch for hello packets from the active and the standby routers. If the active router becomes unavailable for any reason, a standby hub seamlessly assumes the virtual IP address and the functionality.
To enable this functionality, Router MC associates the inside and outside interfaces on the HA devices with a virtual standby group. Inside interfaces belong to standby group #4, while outside interfaces belong to standby group #3. If you have existing HSRP configurations on some of your devices and you want Router MC to use the same identifying numbers for the standby groups, you can specify these numbers in the Configuration Support Settings page under the Admin tab. If you do not specify different standby group numbers, Router MC will disregard your existing standby group numbers and will add standby groups 3 and 4 as usual. See Defining Configuration Support Settings, page 1-3 for information about changing standby group numbers.
Note
See Working with HA Groups, page 1-9 for more information about HA groups.
To use HSRP in Router MC, the hubs in the HA group must have one interface that matches the internal virtual IP subnet and one interface that matches the external virtual IP subnet. Router MC uses this information to determine which hub interface will be the inside interface and which will be the outside interface. The shared virtual IP address must be from this subnet, but must not be identical to the IP address of the interfaces of any of the hubs in the group.
Note
In Router MC, for each HA group, you must provide the following information:
•
•
•
•
See Table 1-6 for a description of the HA Settings page, in which you can provide this information.
Note
Enabling Stateful Failover
You can enable stateful failover for your HA groups. With stateful failover, State Synchronization Protocol (SSP) is used to ensure that state information is shared between the HSRP routers in the HA group. In the event of router failure, the shared state information enables the standby router to maintain IPSec sessions without having to re-establish the tunnel or renegotiate the security associations.
Consider the following before enabling stateful failover:
•
•
Procedure
Step 1
Step 2
Step 3
The HA Settings page appears. See Table 1-6 for a description of the elements displayed in the HA Settings page.
Step 4
Step 5
Step 6
Table 1-6 describes the elements in the HA Settings page.
Table 1-6 HA Settings: GUI Reference
Inside Virtual IP field
Enter the IP address that will be shared by the hubs in the HA group and will represent the inside interface of the HA group. The virtual IP address must be on the same subnet as the inside interfaces of the hubs in the HA group, but must not be identical to the IP address of any of these interfaces.
Note
Inside Mask field
Enter the subnet mask for the inside virtual IP address.
VPN Virtual IP field
Enter the IP address that will be shared by the hubs in the HA group and will represent the VPN interface of the HA group. This IP address will serve as the hub endpoint of the VPN tunnel.
Note
VPN Mask field
Enter the subnet mask for the inside virtual IP address.
Hello Interval field
Enter the duration in seconds between each hello message sent by a hub to the other hubs in the group to indicate status and priority.
Hold Time field
Enter the duration in seconds that a standby hub will wait to receive a hello message from the active hub before concluding that the active hub is down.
Use Stateful Failover check box
Select to enable the use of SSP for stateful failover. To use stateful failover, the HA group cannot contain more than two hubs. This check box is disabled if the HA group contains more than two hubs. See Enabling Stateful Failover for more information.
Apply button
Click to apply your definitions
Clear button
Click to remove your current definitions.
Defining Catalyst VPN Services Module Settings
Router MC supports Catalyst 6500 devices fitted with the IPSec VPN Services Module. This device can be a hub in the VPN managed by Router MC.
When you import the Catalyst 6500 device, Router MC detects the configuration of its ports (routed, access, or trunk). When generating CLI commands for VPN policy, Router MC creates an inside VLAN on the inside trunk interface of the VPN Services Module to which it attaches the required crypto maps. This VLAN serves as the inside interface to the VPN Services Module and is also the hub endpoint of the VPN tunnel. In the VPN Services Module settings, you must provide the IP address for this inside VLAN. The IP address must be on the same subnet as the next hop device after the Catalyst device.
Router MC connects the inside VLAN with the Catalyst's external port according to the external port configuration:
•
•
•
Note
Before You Begin
Select the required Catalyst device in the Object Selector.
Procedure
Step 1
Step 2
The VPN Services Module page appears. See Table 1-7 for a description of the elements displayed in the VPN Services Module page.
Step 3
Step 4
Step 5
Table 1-7 describes the elements in the VPN Services Module page.
Working with Spoke Settings
Spoke settings allow you to specify a spoke's inside interfaces and internal networks, set a spoke's VPN interface, and establish a spoke's hub assignment. They also enable you to define NAT traversal parameters.
Access spoke settings by selecting Configuration > Settings > Spoke Settings.
Spoke settings include:
•
•
•
•
•
•
Specifying a Spoke's Inside Interfaces
A spoke's inside interfaces are physical interfaces or subinterfaces on the spoke that connect the spoke with all the spoke side networks (both attached and internal networks). The subnets that are directly connected to the spoke's inside interfaces, with no intermediary network device, are known as "attached networks." The subnets located beyond the attached networks, that are connected to the attached networks through an intermediary router, are known as "internal networks." See Specifying a Spoke's Internal Networks.
You choose the interfaces on the spoke that will serve as inside interfaces.
Note
Your inside interface definitions have the following purposes in Router MC:
•
•
Note
•
Procedure
Step 1
Step 2
Step 3
The Available Interfaces dialog box appears, and lists the interfaces on the devices in the selected object that are available for selection. See Table 1-4 for a description of the elements displayed in the Show Interfaces dialog box.
Step 4
Step 5
Step 6
Step 7
Table 1-8 describes the elements in the Spoke Inside Interfaces page.
Table 1-8 Spoke Inside Interfaces: GUI Reference
Type list box
Select the physical interface on the device.
Slot list box
Select the slot on which the interface is located.
Port list box
Select the interface's physical port. If you do not select a port, Router MC will include all the interfaces of the specified type in the inside interfaces. For example, if you select Ethernet in the Type list box and do not select a port, the selected interface will be Ethernet *, where * indicates that any Ethernet interface will be included.
Subinterface field
Optionally, specify a subinterface that should function as the inside interface.
Show Interfaces button
Opens the Available Interfaces dialog box. See Table 1-4 for a description of elements displayed in the Available Interfaces dialog.
>> button;
<< buttonClick >> to copy your selections to the list of selected interfaces.
Or, click << to remove your selections from the list of selected interfaces.
Apply button
Click to apply your definitions.
Clear button
The Clear button is only present if Global is selected in the Object Selector. Click the Clear button to remove your current definitions.
Defaults button
The Defaults button is present when any object other than Global is selected in the Object Selector. Click to remove your local definitions and restore the inherited default values.
Specifying a Spoke's Internal Networks
A spoke's internal networks are a group of subnets that reside behind the spoke but are not directly connected to the spoke's inside interfaces. This means that there is an intermediary router located between the internal networks and the networks directly attached to the hub's inside interfaces (attached networks).
Internal networks can be included in your tunnel policy filter definition to specify what traffic to secure in the IPSec tunnel. For example, you can secure all traffic between the internal networks on the hub and the internal networks on the spoke. Router MC uses your internal network specifications to create the required ACLs for the filter options that include the internal networks.
Procedure
Step 1
Step 2
Step 3
•
•
•
Step 4
Table 1-9 describes the elements displayed in the Spoke Side Networks page.
Table 1-9 Spoke Side Networks: GUI Reference
Add a Host/Network field
To add a subnet to the spoke side network, enter the IP address and subnet mask, for example, 192.10.9.0/255.255.255.0.
To add a host to the spoke side networks, enter the IP address or host name.
Add Network Groups field
Spoke side networks can contain other network groups. Select an existing network group from the list and click >> to add it to the spoke side networks. See Working with Network Groups, page 1-13 for more information.
>> button;
<< buttonClick >> to add the specified network/host/network group to the spoke side networks.
Click << to remove the specified network/host/network group from the spoke side networks.
Apply button
Click to apply your definitions.
Clear button
The Clear button is only present if Global is selected in the Object Selector. Click the Clear button to remove your current definitions.
Defaults button
The Defaults button is present when any object other than Global is selected in the Object Selector. Click to remove your local definitions and restore the inherited default values.
Specifying a Spoke's VPN Interface
A spoke's VPN interface is the physical interface through which communication occurs in the IPSec tunnel. You choose which of the spoke's interfaces to use as the VPN interface.
Note
The VPN interface must have a globally routable IP address (unless it is a Frame Relay interface and you are using GRE, or unless the interface has a dynamic IP address, either dynamic or DHCP).
An interface with a negotiated IP address (e.g., a Dialer interface) or a dynamic IP address from a DHCP server, can be used as the VPN interface. Router MC identifies the interface's IP address as negotiated or from a DHCP server, and you must provide the IP address.
Specifications for VPN Interface When Using GRE over Frame Relay
If you are using GRE over a Frame Relay configuration, the VPN interface must comply with the following:
•
•
•
Using the Same Interface VPN Feature
In cases where a single external interface is used to both receive traffic and to distribute it after encryption, Router MC uses the loopback0 interface on the device as the VPN interface.
This feature can be enabled by selecting the Same Interface VPN check box in the Spoke VPN Interface page.
Note
Note
Procedure
Step 1
Step 2
Step 3
Otherwise, if you have selected Global or selected a device group in the Object Selector, do as follows.
Step 4
The Show Interfaces dialog box appears, and lists the interfaces on the device(s) in the selected object that are available for selection. See Table 1-4 for a description of the elements displayed in the Show Interfaces dialog box.
Note
Step 5
Step 6
See Table 1-4 for a description of elements in the Show Interfaces dialog box.
Step 7
For example, if you selected Ethernet 1/0, the Validate Interface dialog box will indicate how many of the devices in your selected object have this interface available. If the selected interface is not available on any of the devices, you must either choose another interface that is on at least one of the devices, or select a different interface on the individual devices that are not covered.
Step 8
Step 9
Step 10
Table 1-10 describes the elements displayed in the Spoke VPN Interface page.
Note
Table 1-10 Spoke VPN Interface: GUI Reference
Select Interface list box
This list box appears only if you have an individual spoke selected in the Object Selector. Select the desired VPN interface on that spoke.
Negotiated IP for Interface field
Only appears when a spoke with a Dialer or Serial interface is selected in the Object Selector, and the interface has a negotiated IP address.
Enter the negotiated IP address. Enter only the IP address, without a subnet.
Interface Type list box
Select the physical interface on the device.
Slot list box
Select the slot on which the interface is located.
Port list box
Select the interface's physical port.
Channel field
If the spoke has a controller, you can specify the channel you want to serve as the VPN interface. This field is filled in automatically if you select an interface with a channel in the Show Interfaces dialog box.
Subinterface field
Optionally, specify a subinterface as the VPN interface.
Validate button
Opens the Validate Interface dialog box that indicates how many of the devices in the selected object contain that interface. See Table 1-11 for a description of the elements in the Validate Interface dialog box.
Show Interfaces button
Opens the Show Interfaces dialog box. See Table 1-4 for descriptions of the elements in the Show Interfaces dialog box.
Enable Same Interface VPN
Select this check box to indicate that a single interface is being used for incoming and outgoing traffic on the device. See Using the Same Interface VPN Feature for more information.
Apply button
Click to apply your definitions.
Clear button
The Clear button is only present if Global is selected in the Object Selector. Click the Clear button to remove your current definitions.
Defaults button
The Defaults button is present when any object other than Global is selected in the Object Selector. Click to remove your local definitions and restore the inherited default values.
Table 1-11 describes the elements displayed in the Validate Interface dialog box.
Specifying a Spoke's Hub Assignment
You must specify which hub will serve as the IPSec peer for each of your spokes, and the interface on the hub that will be the tunnel endpoint interface. This interface must have a globally routable IP address. You can also assign a failover hub to your spokes, to be used if the primary hub fails.
Note
An HA (High Availability) group can be assigned to a spoke as the primary or secondary hub. See Working with HA Groups, page 1-9 and Defining HA Group Settings for information about HA groups.
Hub assignment can be defined on a group of spokes simultaneously, or on individual spokes.
When you create a tunnel policy on a spoke, Router MC writes the appropriate commands to the tunnel endpoint interface on the spoke and to the hub interface assigned to that spoke. This enables the setup and proper functioning of the IPSec tunnel between the spoke and its assigned hub.
Note
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Table 1-12 describes the elements in the Hub Assignment page.
Defining NAT Traversal Settings
NAT traversal is required when there is a device (for example, a PIX device) located between a VPN-connected hub and spoke, that performs Network Address Translation (NAT) on the IPSec flow. This device will be referred to as the middle device.
If the IP address of the VPN interface on the spoke is non-globally routable, the NAT on the middle device replaces it with a new globally routable IP address. Since this change is made in the IPSec header, it violates the checksum of the spoke causing a mismatch with the hub's checksum calculation. This results in loss of connectivity between the hub and the spoke.
With NAT traversal, the spoke adds a UDP header to the payload. The NAT on the middle device changes the IP address in the UDP header, leaving the IPSec header and the checksum intact.
If the middle devices uses static NAT, you must provide Router MC with the static NAT IP address (globally routable) on the inside interface of the middle device, that will be provided for all flows through that interface that require NAT.
However, if the middle device uses dynamic NAT where the NAT IP address is unknown, you must define dynamic crypto on the hub to serve any connection request from the spoke. Router MC will generate the required tunnel configuration for the spoke. See Working with Dynamic Crypto Policies, page 1-21 for information about defining dynamic crypto on the hub.
Note
Procedure
Step 1
Step 2
Step 3
Step 4
Table 1-13 describes the elements in the Nat Traversal page.
Table 1-13 NAT Traversal: GUI Reference
Keepalive field
Specify the interval, in seconds, between the keepalive signals sent between the spoke and the middle device to indicate that the session is active.
NAT IP address check box
Select this check box if the middle device uses static NAT. In this case, you must provide Router MC with the static NAT IP address (globally routable) on the inside interface of the middle device, that will be provided for all flows through that interface that require NAT.
Inside Global IP Address field
Specify the globally routable IP address to be provided for flows passing through the inside interface on the middle device, in the format a.b.c.d. See Defining NAT Traversal Settings for information about the NAT traversal topology.
Apply button
Click to apply your definitions.
Clear button
Click to remove your current definitions.
Configuring Dial Backup
Dial backup is supported on IOS versions 12.3.2XE and higher.
Dial backup can be used to provide a fallback link for a primary, direct connection when the primary link becomes unavailable. The Router MC implementation of the dial backup feature is based on the assumption that two static routes exist:
•
•
Router MC configures a logical dialer interface on the spoke. The dialer interface is associated with a physical backup interface. When the primary route is down, the dialer interface is activated and traffic is redirected through this backup interface, along the secondary route. To ensure that the spoke-hub traffic is encrypted, Router MC applies a crypto map to the dialer interface. This crypto map is identical to the crypto map on the VPN interface (the primary route interface).
The IOS technology, Service Assurance Agent (SAA), is used to detect loss of network performance on the primary route. SAA was previously known as Response Time Reporter (RTR). RTR is still used in the CLI commands for this technology.
Follow the procedure below to configure dial backup on your spokes.
Before you Begin
•
•
Procedure
Step 1
Step 2
Step 3
Step 4
Table 1-14 describes the elements in the Dial Backup page.
Entering Additional CLI Commands (Beginning and Ending Commands)
Router MC enables you to manually enter additional CLI commands and deploy them to the devices in the job. You can add these commands to the beginning or the end of the configurations generated by Router MC for the devices.
When deploying to a file, the beginning and ending commands are shown in the full configuration. When deploying to a live device, Router MC reads the configuration on the device and incorporates the beginning and ending commands into this configuration. Before deploying beginning and ending commands to your devices, you are recommended to view the generated configurations to make sure they meet your requirements. See Viewing Device Configurations, page 1-30 for more information.
Note
Note
Procedure
Step 1
Step 2
Step 3
Table 1-15 describes each element in the Beginning and Ending Commands page.
