The VPN/remote access module exists to perform three functions:
Terminate remote access VPN connections
Terminate site-to-site VPN connections
Terminate dial-in remote user connections
A number of different types of VPN/remote access module design methods can be used, but Figure 11-7 depicts the most hardened method in a large enterprise environment. This can be scaled back in smaller environments, for example by terminating the VPN connections on the firewall instead of separate VPN concentrators .
At the core of this module are the firewalls that provide a different interface for each type of connection to access the internal network. One obvious missing element is full redundancy for interface connections. This is because many VPN termination devices lack redundant interfaces by design, relying instead on software features such as Virtual Router Redundancy Protocol (VRRP) for redundancy. In addition, if you are going to use certificates for your VPN connections, it is necessary that a certificate authority be available for both sides of the VPN connection, though this is best implemented in the public services DMZ of the Internet module.
This module has two entrances. This first is for the VPN traffic and comes from the corporate Internet module. This connection should be filtered at the Internet gateway router to allow only IPsec traffic through to the VPN/remote access module. At a minimum, you should permit the following ports and protocols:
UDP port 500 “ISAKMP
IP Protocol 50 “Encapsulated Security Payload
In addition, you might need to permit the following ports to do IPsec NAT traversal over TCP or UDP:
UDP Port 4500
UDP Port 10000
TCP Port 10000
The second entrance is through the Public Switched Telephone Network (PSTN) for dial-in users. We will look at each connection type individually.
The remote access VPN connections are used for client-based remote access ”for example, a user with a laptop connecting with a VPN client. The users are terminated at a pair of VPN concentrators that provide all of the authentication and validation required to permit the traffic. What is not depicted in the diagram but is used to authenticate and validate the VPN connections is a connection between the VPN concentrator and the AAA server via a management interface that connects to the management module on the internal network.
Once the connection has been validated , the VPN configuration is provided to the remote user, specifying such things as IP address and name servers as well as employing hardening measures such as preventing remote users from employing split tunneling to access the corporate network at the same time they have local LAN access. The traffic is then passed back to the firewall in an unencrypted format, where it can be filtered accordingly . In some cases, it may be acceptable to allow all the traffic through the firewall. This of course begs the question, Why use a firewall at all ? The reason is simple. By using a firewall, you have the means of being as explicit and granular as you want, allowing users to access only those resources to which you want them to be able to connect. In addition, employing a firewall gives you a single quick choke point at which to block traffic in the event of a security incident.
The site-to-site VPN connection is similar to the remote access VPN connection in form, function, and design. The primary difference is that the site-to-site VPN connections represent always on connections, typically to remote or branch offices. Consequently, it may be necessary to permit a wider range of traffic through the firewall to this segment to support the broad range of data and services that may be required.
What is not depicted in Figure 11-7 but is used to authenticate and validate the VPN connections is a connection between the VPN concentrator and the AAA server via a management interface that connects to the management module on the internal network.
The dial-in remote user termination connection is a relatively simple connection compared to the VPN connections. The two routers are configured with modems for analog or ISDN connections, and once the initial physical connection has been established by virtue of the user calling the router, the router uses AAA to authenticate the user using three-way Challenge Handshake Authentication Protocol (CHAP). As in the VPN segments, a connection to the internal AAA server is used for this authentication.
As with all of the perimeter modules, you need to deploy NIDS/NIPS to analyze the traffic and generate alarms. In the VPN/remote access module, you first need to deploy an NIDS/NIPS for the traffic coming from the Internet module primarily to detect reconnaissance traffic targeting your VPN termination devices as well as to detect any non-IPsec traffic on the segment. Because of the filtering to allow only IPsec traffic, if the NIDS/NIPS detects any other traffic it signifies a potential compromise or misconfiguration of the devices on that segment.
In addition, you should deploy an NIDS/NIPS behind the firewall to monitor and analyze all traffic that has made it through the module and onto the internal network.