IPSec LAN-to-LAN Tunnels

The VPN 3000 Concentrator can establish a LAN-to-LAN (site-to-site) tunnel to another concentrator, firewall, router, or compliant IPSec gateway. With this configuration, you can create a secure VPN bridge between your LAN and an intranet remote branch office or an extranet partner's LAN. By utilizing the Internet as the connectivity medium, you can provide a secure, scalable, and inexpensive connection to the remote sites, which you cannot do with legacy solutions such as leased lines or Frame-Relay.

graphics/alert_icon.gif

The CSVPN exam has a tendency to focus on LAN-to-LAN tunnel establishment. It is recommended that you understand the steps involved in initiating a LAN-to-LAN session, in addition to applying advanced features (RRI, bandwidth management, filters, NAT-T, and NAT rules) to these tunnels.


The configuration for LAN-to-LAN tunnels is straightforward. In the Configuration | System | Tunneling Protocols | IPSec | LAN-to-LAN screen, you are presented with a window to add, modify, copy, or delete a LAN-to-LAN session. Figure 6.18 illustrates the Add or Modify screen.

Figure 6.18. LAN-to-LAN configuration screen.

graphics/06fig18.jpg

The top section of the LAN-to-LAN screen deals with the parameters for the tunnel itself. Here, your LAN-to-LAN configuration process begins with naming the LAN-to-LAN session and deciding to which interface the LAN-to-LAN connection is being established (typically the public interface). Starting with software release 4.0, you can specify whether the concentrator can originate IKE tunnel connections, answer IKE tunnel connections, or both (bi-directional). These new options enable the concentrator to maintain backup LAN-to-LAN peers for site-to-site tunnel redundancy. This feature differs from concentrator redundancy with VRRP because the concentrators do not have to be running in parallel on the same LAN. In fact, VRRP must be disabled if you want to use this feature. What's more, unlike VRRP, you can enable concentrator load balancing while maintaining redundancy for the LAN-to-LAN sessions. If the concentrator is configured for Originate-Only, it plays the initiating role in a backup LAN-to-LAN configuration in which it only establishes LAN-to-LAN sessions by cycling through the defined LAN-to-LAN peers until a connection is made. The central location with multiple concentrators will be configured as Answer-Only, in which it only answers LAN-to-LAN session connections, rather than initiates them. The default Connection Type value is Bi-directional, which signifies a non-redundant network in which the concentrator can initiate or receive LAN-to-LAN tunnel requests.

The Peer List field should contain the public IP address of the device to which you are connecting. If your network is designed in such a fashion that there are several backup concentrators at the central site and you chose Originate-Only in the Connection Type pull-down menu, you can specify up to 10 LAN-to-LAN peers on the remote concentrator.

You use the next sets of fields to define the IKE negotiation parameters for this site-to-site tunnel. Namely, you need to decide whether you are using preshared keys or digital certificates for authentication. If using preshared keys, be sure to select None (Use Preshared Keys) in the Digital Certificate drop-down box. Also, be sure to key in the matching preshared key in the designated field on this screen. When using digital certificates for authentication, choose the installed identity certificate you want to use, followed by whether you want to send the entire certificate chain or not. The remaining IKE fields are used to determine the IPSec SA that you are proposing, as well as the IKE SA negotiation proposal.

The following fields determine whether you want to enable many of the advanced features discussed in this chapter. Specifically, you can apply a defined filter simply by choosing it out of the drop-down list. Similarly, you can apply any LAN-to-LAN bandwidth policies that you have previously configured. In instances where the VPN Concentrator is behind a device that is performing some NAT or PAT functionality, you can enable NAT Traversal (NAT-T) to encapsulate IPSec protocols in UDP.

LAN-to-LAN tunnels establish connectivity between the two locations, but how does each side know about the private networks behind the IPSec devices? You must implement some routing mechanism to tell each IPSec device about its peer's private networks. These mechanisms can take the form of static routes or dynamically learned routes. In the VPN 3000 Concentrator, the configurations for a routing mechanism entails the following options:

  • None Do not enable any special routing mechanisms. This option implies that a static route has been configured in the Configuration | System | IP Routing | Static Routes page in which routes to the peer's private networks have been defined.

  • Reverse Route Injection This enables you to define a LAN-to-LAN RRI in which the concentrator injects its private network addresses into the remote concentrator's routing table. This option requires RIP or OSPF running on the concentrator's interface(s).

  • Network Autodiscovery By utilizing RIP, both sides of the LAN-to-LAN tunnel can discover their neighbor's networks. You must enable RIP on both concentrators' private interfaces for this function to work. If selected, you do not need to configure the remaining items on the screen.

graphics/alert_icon.gif

Network Autodiscovery requires RIP to be configured on each of the concentrator's private interfaces.


The remainder of the LAN-to-LAN configuration page deals with specifying the source and destination IP networks that will use this LAN-to-LAN tunnel. In the remaining fields, you can define the local internal network and the remote's internal network by using a predefined network list or by specifying the addresses and wildcard masks in their respective fields. It is imperative to note that the networks defined in these fields should be mirrored in the peer's concentrator or other IPSec-compliant device, as demonstrated in Table 6.2.

Table 6.2. LAN-to-LAN Network Example
 

Concentrator A

Concentrator B

Local IP Address

10.0.0.0

172.16.0.0

Local Wildcard Mask

0.255.255.255

0.0.255.255

Remote IP Address

172.16.0.0

10.0.0.0

Remote Wildcard Mask

0.0.255.255

0.255.255.255

graphics/tip_icon.gif

At the completion of the LAN-to-LAN configuration page, the VPN 3000 Concentrator automatically adds a L2L rule to the concentrator's public interface filter to apply IPSec to the specified source and destination networks. In addition, the concentrator automatically creates an internal group named after the IP address of the peer, as well as an IPSec Security Association for the LAN-to-LAN tunnel.


IPSec LAN-to-LAN NAT

LAN-to-LAN NAT rules are required in instances where both private networks of the LAN-to-LAN endpoints contain overlapping networks as depicted in the diagram in Figure 6.19. In this scenario, devices on each private network do not know how to respond to communicating devices on the remote network because the address is the same as that of their private network. To correct this problem, both sides must translate the internal networks so that the devices can discern between both networks. The configuration for this feature can be found at the Configuration | Policy Management | Traffic Management | NAT | LAN-to-LAN Rules | Add screen. Here you can choose whether you want to perform static 1:1 mappings for internal IP addresses, dynamic translations from a pool of IP addresses, or PAT. After a NAT implementation is chosen, you must define the source network and associate it with the translated network by filling the fields with their respective networks and wildcard mask. Furthermore, you have to indicate the remote networks to which this translation is to be applied. All remote networks are specified by default as determined by the IP address of 0.0.0.0, with a wildcard mask of 255.255.255.255. In the example depicted and configured in Figure 6.19, to overcome the overlapping perplexity, both sides have created a static NAT rule for the internal networks. By translating the identical networks to 172.16.30.0/24 on this concentrator and translating the peer's private network to 172.16.31.0/24 on the remote concentrator, devices can discern between their local private network and the communicating peers on the remote private network.

Figure 6.19. LAN-to-LAN NAT Rule configuration screen.

graphics/06fig19.jpg

graphics/alert_icon.gif

When presented with overlapping networks, it is necessary to perform translation on both sides of the VPN tunnel.


Similar to interface NAT rules, LAN-to-LAN NAT rules must also be enabled on the Configuration | Policy Management | Traffic Management | NAT | Enable screen as displayed back on Figure 6.16. Additionally, it is important to note that when creating the IPSec LAN-to-LAN tunnel, be sure to use the translated networks in the source and destination parameters as opposed to the actual matching private networks.



CSVPN Exam Cram 2 (Exam 642-511)
CCSP CSVPN Exam Cram 2 (Exam Cram 642-511)
ISBN: 078973026X
EAN: 2147483647
Year: 2002
Pages: 185

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net