VPNs provide an alternative to expensive WAN links, but with this alternative come a variety of issues surrounding security, such as authentication and authorization, synchronizing VPN appliance client databases, and centralizing client administration as the VPN network grows.
For a midsized firm, utilizing an authentication database embedded in VPN switches is the most common and easily implemented method for validating clients. This technique works well in a limited environment, but problems arise with synchronizing the embedded databases across multiple appliances as a VPN grows. The synchronization process is conducted manually and becomes an administrative nightmare as users change passwords, which should be occurring every 30 days.
One solution to the synchronization issue is to use a centralized client administration method, such as Remote Authentication Dial-In User Services (RADIUS). RADIUS coordinates authentication and authorization information between the VPN appliance and an authentication and authorization server. Utilizing a centralized RADIUS database server for client administration has numerous benefits, including the elimination of the need to manually synchronize VPN devices. Implementing RADIUS greatly simplifies administrative tasks and reduces the requirement for multiple device updates each time a new client or device change occurs. Implementing a RADIUS server should not require any changes or modifications to a firm’s existing network infrastructure.
Users need to be aware of a few issues with implementing RADIUS servers in their VPN infrastructure. There are a few areas of the RADIUS protocol that are not standardized among vendors. One of these is associated with access-attribute values, the portion of the protocol associated with users’ ability to update their passwords from VPN client software. Utilizing VPN platform and server devices from different vendors has the potential to create choke points within a VPN. To avoid this problem, confirm that the VPN appliance and RADIUS server are, in fact, compatible. This is one area where purchasing both devices from the same vendor is a sound business decision.
Another potential problem is utilizing a VPN switch’s internal client database for administrators, and an external RADIUS server for VPN clients. The VPN switch’s user database needs to be backed up regularly, and this is a manual function. Because logons must be blocked during the back-up process, they may not occur as regularly as necessary and must be done during off-hour support.
Finally, implementing RADIUS servers in a site-to-site environment requires a separate server at each location, due to tunneling issues associated with VPNs. RADIUS is dependent on tunneling, but a tunnel cannot be established through RADIUS. RADIUS must be passed externally to the VPN tunnel. This is achieved either by establishing a VPN portal leveraging a centralized RADIUS server, or by using the Challenge Handshake Authentication Protocol (CHAP), or Password Authentication Protocol (PAP) VPN protocols. CHAP provides an encrypted method of establishing the tunnel. PAP leaves the company’s security policy exposed by providing user identity over the Internet.
The benefits of using a centralized authentication mechanism such as RADIUS are strong. Practices that reduce mundane administrative tasks such aas manual synchronization during off-hours - when remote access is most likely to be used - are a sound, business practice. On the other hand, understanding the issues surrounding implementing centralized client administration is critical to ensuring a sound, security strategy for remote access to company assets.
This story, "Managing the VPN can of worms " was originally published by Network World.