Remote access VPN solutions can become quite convoluted, use several different aspects of communication, and perform different functions given the type of configuration.
These different aspects can be introduced by the concepts of IP address pools and networks.
An IP addresses pool is a predefined group of sequential IP addresses that can be used for assignment to remote systems as they connect. A sequential set of IP addresses is a contiguous block of addresses, of which the following are examples:
192.168.17.1 to 192.168.17.254 provides 254 addresses 10.1.14.3 to 10.1.14.13 provides 11 addresses
As each system is authenticated and a data connection is established, the first available IP address is allocated to the connection. For each subsequent connection, an IP address is used from the available pool. Once the remote session is terminated, the address assigned for that system is released and reinserted into the pool of available IP addresses.
The issue that quickly becomes apparent is: what IP addresses to use? As one might guess, there are several valid answers to the question, and each is associated with a type of implementation concept.
Internally Available. There are several VPN solutions that require the pool of IP addresses to consist of available IP addresses from the internal network to which the VPN device is attached.
As shown in Exhibit 7-11, the internal network is addressed with an IP network of 192.168.13.0, with a subnet mask of 255.255.255.0. The internal network has 200 hosts, each with a unique IP address of that network. The VPN device’s pool of addresses will need to be part of that network and consume the available address space for VPN users.
If in the example the 200 internal systems were addressed from 192.168.13.1 to 192.168.13.200, the VPN device could be configured with a pool that ranged from 192.168.13.201 to 192.168.13.254. Given the amount of addresses allocated to VPN, the solution could support over 50 users.
As datagrams are received from the remote users and passed from the VPN gateway to an internal server, the server sees the source as if on the same network. Once the remote user’s request is processed and the server needs to respond, it handles the packet as if the remote user were on the same network. Normally, this entails the use of ARP. The server’s ARP request is replied to by the VPN device because it is hosting the remote user that is assigned with the IP address. As described earlier, this is a form of proxy ARP to convince the server that it is speaking directly with the remote user who appears to be on the same network.
Internally Networked. In the previous discussion about IP address pools that consist of existing IP addresses on the internal network, it became clear that the VPN solution would be limited by the available IP addresses. An example would be if the VPN device supported 1000 simultaneous connections. In that event, the internal IP addressing scheme would work even if there were no other hosts on the internal network. It is necessary to understand that even the smallest network can conceivably have thousands of remote users accessing services. Application service providers (ASPs) can place several services and clients on a small group of systems located on a dedicated segment. The clients that VPN into the network to access the offsite resources could number in the thousands. Meanwhile, the resources only consume a small network.
To provide for extended remote capabilities without the reassignment of IP addresses for an internal network, a router can be introduced.
Exhibit 7-12 displays a possible scenario when the VPN solution supports many more remote systems than the internal network is designed to address. The router can be used to create a bypass network that can be used to accommodate the vast number of remote systems, but only consuming a single IP address on the internal network.
The VPN device supports 10,000 simultaneous users that must have unique IP addresses provided as they attach. The IP pool consists of an IP address range from 172.16.0.0 to 172.16.254.253, which provides room for ample growth. The router will have an IP address of 172.16.254.254 on the VPN side and an IP address of 192.168.13.201 on the internal network side. As each user connects, they can access the internal network by having all the requests forwarded to the router to be sent to the internal systems. The internal systems can be configured to send all requests coming from the defined network to the router’s internal interface to be forwarded to the VPN device, which in turn sends it to the remote user.
Exhibit 7-11. Internally available IP addresses assigned to a pool.
192.168.13.201 192.168.13.254
192.168.13.0/24 Internet
192.168.13.1
192.168.13.200
Virtually Networked. The two previous solutions described can be construed as clumsy, not necessarily scalable, and possibly difficult to implement in certain environ-ments. Also, the VPN device was acting more as a bridge than a router.
The most desirable solution for remote access VPNs is the creation of a virtual network forcing router-based activities that afford flexibility and will fit into many environments without internal network IP address modifications.
As shown in Exhibit 7-13, the VPN device contains a pool of IP addresses that represents the remote VPN user community. The selection of IP addresses is subject to very few limitations or guidelines; for example,
g cannot duplicate any internal IP addresses
g cannot be Internetroutable IP addresses that are not owned by an organization g should support the number of simultaneous users the VPN device supports The address pool cannot duplicate any internal addresses or network throughout the enterprise that is accessible from the VPN community. If a network in a remote location is not accessible by VPN users, then it does not need to be aware of the VPN community network. Therefore, the remote network can have access to other networks that have the same IP address scheme as the VPN community. However, Exhibit 7-12. Isolated internal network supported by a router.
Exhibit 7-13. Security gateway acting as a router for a virtual network.
192.168.13.201
192.168.13.200 192.168.13.1 192.168.13.0/24 172.16.254.254
172.16.0.0/16
Internet
Internet
172.16.0.0 172.16.254.254
192.168.13.201
192.168.13.0/24
192.168.13.200 192.168.13.1
this should be avoided whenever possible, and the complexities involved are plenty and easily avoidable.
As with any implementation, the use of Internet-routable IP addresses not owned or directly managed by the organization that is implementing them is a recipe for disaster. If the Internet-routable IP addresses are available, their use is not recom-mended due to scalability, cost, and — quite frankly — there is no real advantage.
The pool of addresses represents a network, or group of systems. It is not necessarily a network in the true definition with a subnet mask, but it certainly should be contig-uous. The pool must represent a collection of addresses that can support the incremental aspects of the connection assignment. Providing IP address pools that have gaps will simply not function in many cases in which vendors provide address pool configurations.
As technology has evolved, so has the number of support remote systems. As men-tioned above, several solutions are in the tens of thousands of simultaneously support remote users. The IP address pool must take into consideration the number of simultaneous connections that will be supported. In several implementations, the pool will start small and quickly expand as the solution becomes more utilized. There is no real reason to limit the size of the pool in relation to the supported connections. If there is a lack of IP addresses that are desired for use within the solution, then the solution is oversized or the IP address range needs to be revisited. There have been instances in which the pool is reduced to limit the number of connections allowed at any one time to control access and not flood the device or connection. Most VPN solutions provide a maximum connec-tion configuraconnec-tion that is not associated with the IP address pool.
In most scenarios, a pool is defined that will easily handle the number of system-supported connections and not be duplicated throughout the enterprise. Any connec-tion controls are implemented in other available configuraconnec-tion modificaconnec-tions and not with ambiguous limitations that could lead to horrific troubleshooting issues.
Support for All. Each one of the previous examples typically represents a different product implementation. However, there are a few products that support different configurations, depending on the environment required.
Compatible Systems is a good candidate to explore one of the products that can be configured to accommodate varuous configurations.
As shown in Exhibit 7-14, this simple-looking dialog contains a plethora of options.
There are two sections: the upper section has two radio buttons that allow one to configure a pool of addresses for a virtual network or extend an internal one; and on the bottom are the accessible networks or hosts provided to the VPN client to determine which destinations get IPSec applied.
In the example, the upper section has the value 192.168.13.201 (as shown in Exhibit 7-14) that configures the system to use the internal network, starting from the IP address 201, and going to the end of the defined network, identified by the mask value. The IP subnet mask will inherently identify the network number (in this example, 192.168.13.0 is the network number) and the IP address defined will be the starting point of the sequential assignment until the IP address prior to the broadcast address is assigned to a client system. The broadcast address in the example is 192.168.13.255, therefore leaving 54 available addresses for remote users. If one is wondering, the subnet mask is derived from the internal interface of the VPN system; because the addresses are considered local to the internal network, they must have the same mask. The result is that is no opportunity to enter a subnet mask due to possible conflicts.
However, if the lower of the two radio buttons is selected, the system provides the option of defining a virtual pool of addresses for use.
As illustrated in Exhibit 7-15, the new virtual network is 10.100.0.0/16, immediately resulting in an increase of remote users from 54 to more than 65,000 and the removal of a restrictive internal network addressing scheme. These addresses get assigned sequentially to the clients as they connect and the VPN device simply routes them into the internal network as if part of a remote network.
Thus far, the discussion has focused on the various options of the upper section of the dialog box and the effects each option has on the operation of the VPN device. The lower section of the dialog box provides the ability to define internal hosts and network.
As shown in the previous exhibits, the current internal networks are the 172.16.0.0 range of private addresses and 192.168.0.0/16, which encompasses various internal networks that use the addressing scheme. As an example, every remote office with less than 100 users gets a 192.168 address assigned to it. Of course, this assumes that there are less than 255 of these networks — but that is another issue. The first five networks installed under this design scheme receive 192.168.1.0, 192.168.2.0, etc., until 192.168.5.0. To allow for office additions without reconfiguring the VPN device each time, a network can be defined that includes all the possibilities. Therefore, as the network grows, the VPN device can provide access to them as they come online.
This is nothing more than IP summarization techniques applied to a VPN Exhibit 7-14. Compatible’s address pool configuration based on internally available addresses.
configuration — another wonderful little detail about TCP/IP that can be leveraged to enhance the solution.
The result of this configuration is that the list is being provided to the client upon connection and instructs the client on how to handle requests to the defined values.
Therefore, as the remote client makes a request for 172.16.23.44, it will have IPSec applied and forwarded to the security gateway.
Note: There are several considerations here. The process of providing policy information to a remote client, for many solutions, is leveraging a non-IPSec process or custom set of protocols within IKE. Currently, there is a great deal of work being done with regard to remote user access. However, there are some solutions that follow the IPSec RFCs closely and provide the detailed information in large proposal payloads.
The concept of providing information to the client to define commu-nication activities is a broad subject that falls under the heading of IPSec policies. There are several mechanisms and styles currently being implemented that are proprietary in many cases. Nevertheless, IPSec policies and their distribution are covered in detail in later chapters.
Exhibit 7-15. Compatible’s address pool configuration based on virtual network.