• No results found

Several aspects of VPN communication have already been discussed — from encryption, to authentication, to the introduction of the internal properties of an IPSec VPN. This section discusses the process of determining which data requires IPSec application and how to handle that data once IPSec is applied. As an example, Cisco uses ACLs within the IPSec communication configuration to identify interesting traffic to apply IPSec security services.

As detailed previously, IPSec operates in the network layer and uses an application to allow users and administrators to interface and configure how IPSec operates on the system. Client software typically supports a mechanism to instruct the network layer operations on how to manage data flowing to and from the system, based on desired policies. The incarnation of the administrative interface is sometimes referred to as a map and can exist in several formats, ranging from a simple text file located on the system’s hard drive to a complicated set of parameters that exists only in memory.

A map associates requested destinations with a gateway that provides service to that destination. In the event that a request is made for a destination that is not part of the map, the request is forwarded based on the original attributes and IPSec is not applied.

Maps are used to represent the administrative link between the SPD and SAD.

A remote user has connected to the Internet and the central office is also connected to the Internet by means of a VPN gateway. The user is assigned an IP address by the ISP providing the connection. The user makes a request for www.yahoo.com to browse the Web. Yahoo.com get resolved to an IP address, 204.71.202.160. As the request passes through the network layer, IPSec investigates the destination IP address and compares the result with the map. The map does not contain any attributes for the destination IP address and therefore forwards the request to the remaining network layer operations and a session is established to www.yahoo.com.

However, in the event the user makes a request for an IP address defined in the map, the operation of the communication is much different. Exhibit 7-16 displays an

Exhibit 7-16. Checkpoint secure remote installation map.

Exhibit 7-16. Checkpoint secure remote installation map. (continued)

example map from a Checkpoint Secure Remote installation. Secure Remote (SR) is Checkpoint’s current VPN client solution that installs on a system to provide VPN services for accessing a VPN network hosted by a Checkpoint firewall. Prior to using SR the user must obtain specific information from the firewall to allow future commu-nications and discover what networks and hosts are accessible via that particular gateway.

Typically, an administrator or help desk will provide the firewall’s IP address or Fully Qualified Domain Name (FQDN) to initiate communications. Once this data is config-ured, the client software requests a configuration file, or map, that represents the properties of the firewall.

Map Example Internals. Several parts of this file provide a great deal of information about the structure of the VPN. However, for this particular exercise, the focus is on the information in bold.

The first thing in bold faced type is a section labeled gws; this simply defines the firewall and the necessary attributes that pertain to the VPN support of the gateway.

The initial value is CHKP.IP440, which represents the firewall object defined in the firewall’s database. This will be used throughout the file to represent the firewall’s identification. Also, the suffix infers that the firewall is a Nokia IP-440 firewall appliance.

:gws (

: (CHKP.IP440

The next three entries define the firewall’s object IP address, specify the key manager, and provide the IP addresses assigned to all the defined interfaces within the firewall.

The type “refobj” allows the remainder of the configuration file to reference back to this object.

Exhibit 7-16. Checkpoint secure remote installation map. (continued)

:cache_passwords (false)

The section that directly relates to the concept of a map is topology. The topology section is a collection of predefined objects that can be reference to determine where to forward data.

The name references the original firewall object defined in the beginning statements.

The type assists the client in determining the kind of system that is being defined and its role in the VPN. The ipaddr and ipmask are standard TCP/IP address identifications.

The all 1s subnetmask signifies a single IP address and not a network. In this example, there are three gateways defined for each interface.

The next two sections (See Exhibit 7-16) relate directly to destinations that are supported by the gateway. The firewall has three interfaces, one connected to the Internet and two others for internal networks. The first entry is a network called

“Net-10-1-2” that is defined with the IP address 10.1.2.0/24. When the client makes a request for any system that has an IP address of this network, IPSec will intercept the communication, apply the security defined in the policy, and forward it to the owner of the object, in this case CHKP.IP440.

: (

However, in the second entry, a single system is allocated for the second internal network. If the remote user were to make a request to a system with the IP addresses of 192.168.1.45, the request will have IPSec applied and be properly forwarded to the gateway. If the user attempts to access any other system that may be on the 192.168.1.0 network, the request will be sent to the Internet.

The IP address of the destination can be private IP addresses or Internet routable addresses. This brings up an interesting scenario if a network is not using private IP addresses for internal use but rather Internet-routable IP addresses that are arbitrary.

The use of Internet-routable IP addresses that are not owned by the operators of the internal network is becoming increasingly rare. However, of the cases that remain, a VPN solution will force the change of the internal IP addressing scheme to private

IP addresses. An example wherein this scenario causes a problem is if a request from a remote user is made to 202.12.3.24, which is part of the VPN, it will never be forwarded to the Internet. If the 202.12.3.24 IP address is assigned to a valid Internet resource, the users and networks of the VPN will not be able to access it. A single IP address does not pose much of a problem; however, if large ranges of IP networks are addressed, the problem can be crippling.