One of the annoying aspects of implementing VPNs – getting them to work across corporate firewalls – could be resolved soon based on work by the Internet Engineering Task Force.
During its recent meeting in London, the standards-setting body reviewed a proposed standard for network address translation (NAT) that would spell out how IP Security (IPSec) VPN tunnels should traverse firewalls and other NAT devices.
Ideally, firewalls and VPNs complement each other, with firewalls blocking intrusion from the Internet and VPNs providing a way to extend secure encrypted tunnels across the Internet to connect network devices. But sometimes, firewalls and VPNs don’t work well together, especially when different vendors make the VPN equipment.
Take the case of Bell Canada Enterprises Inc., where employees use the Nortel Networks Corp. Contivity VPN client on their laptops to remotely establish secure tunnels to a Nortel Contivity VPN switch. When Bill O’Brien, associate director of systems security at the company, decided to add personal firewalls to the laptops to boost security, he tested half a dozen. O’Brien discovered that only one of these products, InfoExpress Inc.’s CyberArmor, would reliably let Nortel’s VPN software establish VPN connections.
“The desktop firewall and the VPN have to work together,” O’Brien says. “Hackers are always looking for the weakest links.”
In general, much of the problem Nortel and other users have experienced has to do with NAT or related port address translation technology, both of which substitute a private IP address with a public one for Internet traffic. Often, customers give LAN devices private IP numbers because they can’t get enough public IP addresses or they want to mask their machines from the Internet. When a NAT firewall or router sends outbound traffic through the firewall, the firewall translates that private address to a public one. It translates in reverse for incoming traffic.
Because IPSec VPN devices create new IP headers for tunnelled traffic, packet authentication checks can fail, and tunnelled traffic can get dropped by firewalls performing NAT. Individual vendors have found ways to work around this, but there is no single agreed-upon method for doing it among vendors. The IETF proposal could become this single method.
The IETF proposal calls for wrapping up the IPSec traffic within a User Datagram Protocol (UDP) header before NAT occurs. Integrity checks on these UDP wrapper headers can be made successfully despite NAT.
This proposal is a combination of suggestions written by several vendors, including Microsoft and RedCreek.
No serious objections were voiced about the draft at the IETF meeting this month, but it has not been elevated to the status of a standard, according to Paul Hoffman, a member of the IETF. Members of the IETF committee handling the proposal are continuing their on-line discussion of it.
While VPN use is increasing, interoperability among different vendors’ equipment is not ubiquitous, and this includes how they deal with NAT problems. And these combined firewall-VPN products are becoming more popular. By 2004, 52 per cent of firewalls will include VPN support, according to market research firm IDC. Last year, 23 per cent of the firewall appliances sold included VPN support, IDC says.
In the meantime, customers have to decide the best course of action based on their current network equipment.
Ken Venner, CIO at chipmaker Broadcom, says his company uses a collection of VPN gear made by Cisco, Nortel and RedCreek as well as a Check Point Software firewall. But Broadcom is dropping the Nortel VPN because it doesn’t handle NAT well with the Check Point firewall. “If there were an adopted standard, I probably would have had only one software VPN product and one or two hardware-based VPN products,” Venner says.
As you might expect, vendors that have worked out their own answers to the NAT problem and sell integrated VPNs and firewalls say their gear is the best way to go. Check Point chairman Gil Shwed claims that buying the VPN and firewall separately is too costly and expensive.
“You need to manage two policies, two sets of systems and that’s simply too expensive, not only in the fact that you have to purchase two boxes, which obviously costs more than purchasing one, but also in managing on a day-to-day basis,” Shwed says.
But separating the VPN and firewall allows for more flexible configurations. Richard Palmer, vice president of VPN and security at Cisco, cautions there is no one-size-fits-all answer. But in Cisco’s experience, larger companies buy the VPN and firewall separately because that configuration allows building larger networks.
“Most large enterprise customers typically do not use a VPN/firewall combination,” Palmer says. A typical configuration, according to Cisco, involves running the VPN gateway and firewall in parallel, with the corporate router directing IPSec packets to the VPN gateway and non-IPSec traffic to the firewall. That way, the VPN traffic doesn’t actually pass through the firewall because the VPN tunnelling is considered to provide an appropriate security level.
Despite the fact VPN vendors implement the IPSec VPN standard differently and that firewalls handle security in a number of ways, combining firewalls from one maker with VPN gear from another is still possible.
Some vendors and service providers take on the integration work themselves, making it easier for end users to implement the products. Cisco, for example, doesn’t offer a desktop firewall of its own, “so we do a lot of interoperability testing ourselves with personal firewall systems that our customers ask us to check out,” Palmer says.
Internet service providers, including WorldCom, are also documenting how to successfully piece together firewalls and VPNs. “We have a number of standard configurations and have our engineers certify the configurations,” says Audrey Wells, senior manager of IP VPN services for WorldCom. These certified configurations are then used in customer networks, she says.
But once a standard is in place and widely adopted, users won’t have to worry about NAT anymore says Chris Welles, a development manager with VPN equipment maker SafeNet. “Ideally you want something that you can just put in, and it works without having to configure anything,” Welles says.
