
Installing a VPN, while normally a one-time job, is a complex task. Add a CA, and the process becomes even more difficult. Once installation is completed, you have full control over your VPN, including policy and certificate management of end users and devices. PERMIT Enterprise is managed through three different consoles: Entrust Manager covers the CA and X.500 directory server, allowing you to issue and revoke X.509 certificates; PERMIT Director allows you to manage the relationships (Security Associations SA) between VPN devices by publishing attribute certificates back onto the X.500 directory; and PERMIT Config provides gateway management. The CA, PERMIT Director and PERMIT Config can all be located on different workstations for added security.
Once Entrust is set up, adding gateways and tunnels to the VPN requires several steps. Using PERMIT Director, we imported our users from the X.500 directory and moved them into groups. In PERMIT Config, we pointed our 4520s to the Entrust CA and X.500 directory. Setting up the VPNs is a simple matter of setting rules on each 4520, and designating the subnet and hosts that will participate in the VPNs. We had to set up several subnet ranges because we had the management station and CA behind one of the gateways, and we had an SNMP manager "outside" the VPN that needed unencrypted access to internal resources.
Once we had each VPN configured, we built a secure map within PERMIT Config describing the available subnets and the gateways that provide access to them. This map file--essentially a routing table--is sent to each gateway participating in the VPN. Also sent to the gateways is the security profile file that defines the acceptable combinations of authorization and encryption schemes for the 4520. We then had to reboot the gateways (unlike the VSU 1010) for the new policies to take effect, which is disruptive to the network. You need to be careful when you reconfigure the devices. We found this multistep process rather cumbersome and convoluted, and the need to reboot the 4520 after making a change to the VPN configuration contributed to its low Tunnel Management score.
Reporting and logging was also lacking in the PERMIT 4520. Logged information from the 4520 comes in volatile and non-volatile forms; the difference is persistence between power cycles. Statistics on the traffic passing through tunnels is pretty weak, unlike comparable stats with LanRover VPN Gateway. The only traps sent to our SNMP manager were warm reboots. SNMP traps about security problems such as tunnel failures are significant enough to be brought to a network manager's attention.
There are two log-file types. Non-volatile logs contain information such as system restarts and reasons for shutdowns, certification events, and other information deemed important enough to remember over the system restarts. Volatile logs track events such as IKE negotiations between two gateways, and remote management sessions. Volatile log events are concerned with sporadic activity. By reading the volatile logs, you can discover what types of tunnels are being requested and how often, and who (what IP address) is making the request. Note that there is really no easy way to get information on the tunnel types other than taking a rather painful stab at reading through the log one line at a time.
Shiva Corp. LanRover VPN Gateway (Beta)
Shiva's LanRover VPN Gateway solution was initially tested using manual IPSec, which is tightly integrated into the management station. During our testing cycle, Shiva released a beta version of its IKE code (scheduled at press time for a mid-July release), which we used during re-evaluation; however, the IKE functionality wasn't yet part of the management station so we configured the tunnels through a terminal on each device. In evaluating the VPN Gateway, we looked at the management station for general management and assessed it by building manual IPSec tunnels; we assumed that Shiva's management functionality would show through when IKE was fully integrated with the product. Shiva was scheduled to begin ICSA certification in mid-June, and be finished in mid-July.
The VPN Gateway excelled at reporting and logging, supporting both Unix syslog and SNMP monitoring. However, performance degradation reached 31 percent, the worst showing in our testing. The VPN Gateway does ship with Shiva's CA, but it currently only supports ISL (Shiva's proprietary tunneling). IPSec/IKE is slated for release in the fourth quarter of this year.
Shiva's support for logging and SNMP monitoring is unique among the products in this roundup. With multiple levels of syslog message severity, you can adjust the verbosity to suit your needs. The debug level is used for troubleshooting while the warning level is for normal operation. At the debug message level, we were able to track the IPSec and IKE negotiation in detail and readily see errors. Other system messages are sent to syslog as well, which gives you a single formatted file to store status data. Also unique to Shiva is support for SNMP monitoring. Using CastleRock's SNMPc 4.1n manager, we were surprised to see the VPN showing on the devices as virtual ports. Looking at the detail of the ports, IPSec tunnels successfully negotiated were reported in an "Up" status while tunnels that failed were flagged as "Down," as well as getting other interface-related data.
|