Ensure your success - integrating VPNs with established infrastructure components - Internet/Web/Online Service Information

Communications News, March, 1999 by Brendon Howe

Know how to integrate VPNs with existing network architectures.

As corporations begin production deployment of virtual private networks (VPNs), an unexpected challenge emerges--the problem of how to integrate this new network with existing infrastructure components [remote access server (RAS), routers, firewalls, and authentication systems]. Integrating the old with the new is perhaps the most significant hurdle standing in the way of users realizing the promised benefits of a VPN.

It's commonly believed that conventional routers and firewalls provide the capabilities required of a reliable enterprise VPN. Although these devices provide a subset of functionality found in a VPN system (secure tunneling protocols), they don't provide all of the features and scalability requirements needed for production VPNs. For example, most routers do not monitor or control end-user traffic flows--needed to monitor and perhaps control usage costs--and often lack the specialty features and processing power required for large-scale VPN traffic processing. Firewalls provide effective end-user authentication and security enforcement but cannot scale performance across an enterprise network of thousands of users.

PROTECTION

Dedicated or specialty VPN systems address these critical issues of functionality and performance. The challenge for users is to integrate the new-generation VPN systems without a complete enterprise network overhaul.

As companies migrate to VPN for remote access, consideration must given to leverage existing RAS whenever possible. There are compelling reasons to do so; RAS solutions have been purchased and are in place (it works!) and provide secure and predictable connectivity. The task of RAS integration falls solely on the VPN system's ability to use RAS as a connectivity option for VPN users, depending on who the user is, where they are dialing from, etc. These user "policies" are configured centrally by the network administrator and must be enforced locally for all VPN users.

VPNs must abide by the network address infrastructures (routers) in place, since it's unlikely that an organization will restructure the corporate IP addressing scheme to accommodate a new VPN. The most significant issue with this is that VPN users must be assigned IP addresses (in addition to their local POP-assigned address) in such a way that corporate hosts are reachable via the VPN (tunnel server). Not only must the tunnel server support routing (to learn and advertise routes and to forward packets), but the clients must also be assigned IP addresses in a structured and meaningful way. Some may be statiscally assigned, while others may be allocated via a dynamic pool, depending on the policy settings established by the network administrator.

IP addressing techniques for clients are important for another reason: most companies today establish and enforce access controls and authorization rights based on IP address. Maintaining a consistent approach--where a user gets assigned to the same subnet or IP address independent of how he connected--yields a much more controlled environment that is easier to administer.

PROTECT THE PROTECTION

Placement of the VPN system relative to the firewall(s)--both at the remote and central site--is another important integration issue. While firewalls provide a critical security function in the enterprise network, they're not set up, by default, to allow VPN traffic through. As a result, firewall reconfiguration is needed if VPN traffic is to flow through them.

The figures show two popular firewall-integration techniques. In the first, the VPN tunnel server is located behind the firewall, an approach that is considered by many to be more conservative, since the firewall continues to be the central security point for the entire network. Though it may be a conservative approach, it requires reconfiguration of the firewall to allow VPN traffic through PPTP (TCP port 1723 and IP protocol id 47) and/or IPSEC (UDP port 4002 and IP protocol id 50). This approach also subjects the firewall to all VPN traffic, a potential problem if the firewall's performance cannot scale along with the VPN.

The second figure shows the VPN tunnel server connected in parallel with the firewall, an approach in which all VPN traffic flows through the tunnel server (assuming that authentication and encryption checks are passed), while all non-VPN traffic is subjected to the firewall. This approach has advantages over the previous one while maintaining the highest level of security. It provides the highest level of performance and scalability available through the "specialty" VPN system, and it doesn't require any firewall reconfiguration. For these reasons, this approach tends to be the most popular design option.

Companies with RAS solutions in place likely use a RADIUS server for user authentication; it obviously makes sense to leverage that approach in order to minimize configuration tasks. VPNs that support a RADIUS client will "proxy" the authentication request to the existing RADIUS server, greatly leveraging the existing user/password database. In addition, some VPNs will allow IP addresses to be assigned via the RADIUS database (look for this feature!), further leveraging the existing database.