Let's clear the air about NAT and firewalls once and for all. A firewall controls access across a border point. That means you can allow some traffic to pass while denying other traffic. The rules used to allow and block traffic are better known as your security policy. With these rules, you can control access based on numerous fields in the data packets, like IP addresses, port numbers and application data.

NAT, on the other hand, simply translates IP addresses on one side of the NAT gateway to something on the other side (for an explanation of NAT, see "Network Address Translation: Hiding in Plain Sight"). Depending on how a vendor implements NAT, you may be able to create NAT rules based on the same information you use to create firewall rules. But the only thing NAT does is alter IP addresses -- period. Any security gained with NAT is a useful side effect (see "NAT Security Side Effect," below). Some NAT devices let you define internal rules to allow inbound connections to internal servers by statically mapping an external port number to an internal server, but that is not firewalling.

The distinction between a firewall and a NAT is important because a well-defined and strategically implemented security policy will control traffic in either direction across a firewall. Certainly, you want to control traffic passing from an untrusted network, like the Internet, to an internal network, and we all know you can do that with a firewall. Yes, you can also do it to a certain degree with a NAT router. But you want to control traffic leaving an internal network -- this is called egress filtering. In many cases, common protocols, like HTTP, HTTPS (HTTP Secure), SMTP and DNS, are all that are needed for employees to work outside the internal network, and you can always add more protocols if necessary. By limiting outbound access, you have made attacking and exploiting an attack much more difficult.

Although a NAT is not a firewall, a firewall can perform NAT. In many cases, having NAT on your SOHO firewall will be required because, like most organizations, your company can't get its own address space or enough address space to support all its remote sites.

It is well-known that IPsec VPNs fail when crossing NAT routers because many NAT routers don't know how to handle IPsec traffic (see "Why Can't IPsec and NAT Just Get Along?"). Nexland's IPsec-aware NAT router, ISB2LAN, is among the exceptions. Unfortunately, though, the disconnect between NAT routers and IPsec VPN traffic holds true with NAT-performing SOHO firewalls as well.

Add a Little VPN

What you really need is a SOHO firewall that also runs VPN. Because of IPsec interoperability problems in shipping products, building out a successful multivendor environment is tricky at best. You're better off buying SOHO firewalls that are supported by or are in the same product family as your firewall or VPN gateway.

Supporting VPN natively on the SOHO firewall eases many management problems. You won't have to support clients on the desktop; just think what that entails: installation, updates, configuration management and remote troubleshooting. It also makes things easier for end users because they don't need to do things differently because of their location -- in the office or at home.

What features do you need on your VPN-supporting SOHO firewalls? First consider the central site. Your central site VPN gateway must be able to create dynamic VPNs regardless of the originating IP address. Broadband users, for example, often receive their IP addresses via DHCP, and the range changes over time. Unless you want to spend time updating network maps with DHCP ranges, having a wide-open configuration policy will save you time. Bear in mind, however, that you need to enforce strong password policies since the VPN gateway will accept connections to the world.

Next, if you allow SOHO users to surf the Internet, make sure you can control the path traffic takes. You can force all traffic over the VPN, then route it out to the Internet from a central site. This configuration provides the best traffic control because you can enforce a central security policy. On the other hand, paths will be longer, and that will hurt performance. Some VPN products provide a feature called split tunneling whereby traffic destined for protected networks is stuffed into a VPN, and all other traffic simply runs through the firewall to the local ISP, which can result in better performance. There is a downside, though: Split tunneling robs you of some control and security.

It also helps to remember that home connections are often not for business use alone. Unless your company is providing separate broadband connections just for the remote worker, expect to provide some support for family entertainment, like online gaming and streaming media.

If you roll out SOHO firewalls, you have to manage 'em -- and that ain't pretty. You'll face several problems, such as locating the devices, securely communicating with them, updating the system configuration and software, and troubleshooting related specifically to SOHO firewall management.

Firewall management has always been a difficult, largely manual process. This is especially true when there's more than one firewall involved because you must update, maintain and archive security polices. If you're working in a multivendor environment, you'll need to add using multiple management consoles and dealing with various feature sets to your list, all of which raise management costs.

More important, many SOHO firewalls are aimed at the consumer market, and each has a single interface with which to manage it. So if you have 50 firewalls deployed and want to make a policy change, you'll have to touch all 50 firewalls. Not only is this time-consuming, but it increases the risk of error.

Many vendors, including Check Point Software Technologies/Nokia, NetScreen Technologies, SonicWall and WatchGuard Technologies, have complete product lines that support NAT, firewall and VPN -- and all products are manageable through common management applications. The applications range in price from free to several thousands of dollars, but no matter the cost, they will save you remarkable amounts of time and money in the long run. Applying this feature to our 50-firewall scenario described above, you'll be able to make the change on all 50 firewalls in far fewer steps. You'll also have an easier time archiving and managing polices.

If you're managing firewalls over the Internet, make sure management messages are encrypted to prevent snooping. In products that support VPN, use the VPN as the secure envelope and manage the SOHO firewall from the internal interface. That means that each SOHO internal network will have to be uniquely addressed to properly route packets to the correct firewall. Some products also support SSL (Secure Sockets Layer) for management, and in these cases you can manage the firewall from the external interface. In any event, make sure management communication is secured.

To manage remote firewalls, you must have your equipment tell the central management system that it's online and provide its network address. This is often achieved through proprietary heartbeats sent from the SOHO firewall to the central management server or firewall. Thus, you can both remotely manage a device in a dynamic environment and know if it's connected and available to the Internet. This is a very useful feature when you're trying to troubleshoot lost connectivity problems. We're starting to see SOHO firewalls supporting DDNS (Dynamic DNS), a protocol that updates DNS records with current addressing information.

Along with management functions, make sure your SOHO firewall system supports centralized logging. SOHO firewalls -- any firewalls for that matter -- are not fire-and-forget defenses. They must be monitored for unusual activity. SOHO firewalls that support syslog logging, SNMP traps and other event reporting will integrate into almost any management system running. Look for proprietary or Web-based monitoring tools because syslog and SNMP traps will alert you when there's a problem, while passive report-based monitoring tools require you to view the logs constantly.

Be careful with event reporting, however, because you can easily spam yourself with messages from multiple devices. If you're deploying a large number of SOHO firewalls, make sure you can define what events get reported and how they are reported. For example, port scanning is a fact of networked life and nothing to get excited about. However, you will want to know about an active denial-of-service attack like a syn flood. Selecting the events that are important will go a long way toward easing monitoring chores.