Network Computingwww.networkcomputing.com

Staying Connected

Because they are adjacent to network boundaries, firewalls are a single point of failure. Since network downtime can be so costly, redundant firewalls make sense. In previous versions, Brick failover was available only when external load-balancing products surrounded the Brick. Now failover is supported natively. Multiple Bricks are configured into a domain of associated Bricks. When a Brick boots up, it broadcasts its identity and looks for other Bricks in its domain. If none are found, the Brick sets itself up as the primary firewall. The next Brick that boots up locates the primary Brick and sets itself to passive mode. Any changes made to the Brick configuration or firewall state tables are communicated from the primary Brick to the backup Bricks. The primary Brick can choose the best interface--gigabit rather than Fast Ethernet, for example--and send updates to the backup Bricks, or you can set the interface for each Brick manually.

I installed two Bricks on my network by running a crossover Ethernet cable between the two firewalls and enabling failover. Using Spirent Communications' SmartFlow application, I started several streams of UDP traffic to Port 53 simulating DNS queries through the network. Then I pulled the plug on the primary Brick. The secondary took over without a hitch.

LSMS also features redundancy for management high availability (HA). The LSMS HA installation is slightly different for the backup Bricks because their LSMSes have to set up database replication and therefore need to know the addresses of the primary LSMS. Once in failover mode, the primary LSMS replicates changes to the backup LSMSes as they occur. Additionally, the Bricks use a heartbeat to autodetect when an LSMS has failed, and will "rehome" to the backup LSMSes in the order designated in their configurations. I tested this feature by shutting down the primary LSMS. After 30 seconds, the Bricks rehomed to the secondary LSMS. Bricks will rehome to the primary LSMS if configured to do so, and the Bricks can be rehomed manually to a different LSMS.

Playing 802.1Q Tag

From an infrastructure standpoint, Brick is more of a Layer 2 bridge than a Layer 3 router, meaning it sits transparently on the network. Lucent has taken this one step further by supporting 802.1Q VLAN tagging. I tested this by setting up a gigabit fiber port with multiple VLANs. Unfortunately, the Brick doesn't autodetect the VLAN numbers on a port, so I had to add the VLANs to the Brick. Once that was done, I could add firewall rules based on VLAN assignment rather than IP address. This feature is geared toward service providers whose customers are assigned specific VLANs and that carry a number of servers across a range of IP addresses and for which it would be inconvenient to add individual rules for each server. I created a security policy that set a rule to allow only HTTP traffic from VLAN 2 and another rule to allow FTP traffic from VLAN 3 (see screenshot). All other traffic was to be dropped. The policy tested successfully. Next I changed the IP addresses of the HTTP clients and servers. The Brick continued to pass traffic based on the VLAN-based rules, regardless of the IP addresses I used. I could have further refined the policy by adding an IP address restriction as well.

Lucent's VPN Firewall and Security Management Server (screen view) Click here to enlarge

Securing the Desktop

Like other firewall vendors, Lucent has chosen to feature a new, albeit rudimentary, desktop firewall in LSMS 6.0. Once it is installed, the firewall is active at all times and has its own policy. Unlike Check Point Software Technologies' SecureClient NG desktop firewall, which has a configurable policy, Lucent's desktop firewall has three policy states: pass all traffic (no firewall); block all traffic (except for VPN traffic, keeping you off the network); and pass only user initiated traffic (users connect but others cannot connect to them). The policy selection is set by the administrator and, as with other desktop firewalls, the policy is updated upon successful connection of the VPN and policy download. I installed the firewall on a Microsoft Windows 2000 Pro workstation and tested all three modes, which worked as advertised.

Next I tested the UDP VPN encapsulation designed to defeat problems occurring with NAT. Unlike offerings from Check Point and Nortel, Lucent's version does not provide autodetection of NAT between the client and gateway. The end user must activate UDP encapsulation manually. Setting up NAT encapsulation is easy--I set the default client policy to support UDP encapsulation and set the port number to 10000. The default port number is 501. Using a Cisco 4700 as a NAT router, I made a VPN connection to the Brick and manually selected UDP encapsulation. Once I was done, the traffic flowed as expected.

Reporting and Monitoring

When I last looked at the LSMS (see "Lucent Security Management Server 5.0 Gets a Face-Lift"), I thought the reporting and monitoring were pretty lame, though I liked the firewall. Lucent has done much to improve both reporting and monitoring. Lucent Logviewer presents session, user authentication and system events in a sortable format. Relevant details, such as source and destination addresses, port numbers, date and time stamps, as well as session details, are available immediately. Sorting the log file--500 pages of entries--did take some time, though. To reduce the number of entries, I used Logviewer's powerful filtering capabilities to display only a subset of sessions available.

A hot new monitoring tool, the Status Monitor, provides an ongoing snapshot of all the Bricks under the control of the LSMS. This includes the number of known Bricks that are up or lost, the total number of packets in or out of the Bricks, and the number and types of sessions passing through the Bricks--all useful information. You can find more detailed information and graphs by drilling into each row.