A Tale of Two Tunnels

Like any security decision, choosing the right equipment and software isn’t something you should take lightly. If you’re looking for a “plug-and-go” firewall for your small business—along with the ability to set up a solid VPN—SonicWALL can fulfill that need.

• By Roberta Bragg
• June 01, 2001

January 2000. Windows 2000 was just around the corner. Like many of you, I was deep in doo-doo. There was a lot of new information to learn and new techniques and practices to struggle with. Each project I worked on was colored by indecision: Go with the tried and true—or propose a Win2K solution? The answer wasn’t always clear. In one case I was asked to set up a virtual private network (VPN) between two offices of a small company. It wanted to connect its offices over the Internet but was concerned—and rightfully so—about exposing its private business traffic to the public. Because of its size, lack of in-house technical staff, and the fact that it already had a SonicWALL SOHO firewall at headquarters, I installed a second SonicWALL SOHO at the branch office and utilized the VPN capabilities of the devices to create the tunnel. This year, we revisited the situation and migrated to a Win2K solution. The decision, each time, was the right one.

What’s in a Name?
Before you can expect to make VPN choices for your organization, you ought to make sure you’re on track with what a VPN is. The market is less fragmented than it was; but still—when I say VPN—will you all agree? Here are the definitions that I use to characterize the process:

• Virtual—The connection between two networks is between two endpoints or gateways. While it may traverse multiple networks and take many paths, it operates and appears to be—to the clients on either side—a simple point-to-point connection. This simple-appearing connection, or virtual path between the two networks, is often referred to as a tunnel.
• Private—All data that traverses the tunnel is also encrypted, and all data travels from one end-point to another. There’s no insertion of data mid-tunnel.
• Network—The connection ties two different subnetworks so that—to communicating computers on either side—it looks like one network.
• Encapsulation—Packets transmitted over the VPN are wrapped inside another packet provided by the VPN protocol used. This wrapper helps protect the packet and also provides the routing address needed by the LAN packet to travel over the Internet (or some other third network).

Security in a Box
This month I’ll detail the SonicWALL solution. Next month it’s Win2K time. SonicWALL provides a variety of hardware-based firewall solutions, many of which have VPN capabilities. These boxes range from the small plastic “TELE” for telecommuters and the plain, blue, plastic SOHO meant for small business and home offices to the rack-mountable SonicWALL PRO.

Like any security decision, choosing the equipment and software for the job isn’t something you should take lightly. It’s a little disconcerting at first to put your trust in something that weighs in at a mere couple of ounces, but the product does perform the functions it was designed for. If you’re looking for a “plug-and-go” firewall for your small business, SonicWALL can fulfill that need.

To install, you simply place the device with the WAN port connected to the Internet and the LAN port connected to your network. Enter appropriate IP addresses into the SonicWALL browser-based interface and, by default, all traffic to the Internet is allowed and all traffic from the Internet is blocked. (You’re responsible for making sure all Internet traffic passes through the SonicWALL. Only traffic that passes through a firewall can be regulated by the firewall.) This isn’t the ideal, complete solution. You should probably block some LAN-based traffic and you may need to allow some Web-based traffic—such as access to your Web site. However, it’s a start and—for many small companies—a reasonable choice. SonicWALL offers the capability to configure its firewall solution to open and block traffic by port type through a straightforward interface, so you can customize the firewall to match most requirements.

Now comes the hard part. Like most firewall products, SonicWALL offers a rich set of additional and—depending on the model—optional features such as content filtering, virus checking, and the ability to create a VPN. Note the words “ability to create a VPN.” I was lucky, I had the opportunity to snag a couple of SonicWALL SOHOs and build a test lab before having to establish the VPN in the real world. My first experiences weren’t cakewalks.

The product offers the ability to create a VPN end point for access via special client-side software and the ability to create a gateway-to-gateway VPN by establishing a tunnel between two SonicWALLs. It was this latter solution that we wanted, and here’s how the testing progressed.

In the Lab
To test any VPN gateway solution, you must have the ability to establish at least three networks in the lab. Figure 1 shows the design we used.

Figure 1. In the test lab, computers in Network A simulated the corporate headquarters sitting behind SonicWALL A, and computers in Network B simulated the branch office sitting behind SonicWALL B.

Routers A and B provided routing across our fake Internet and allowed simulation of the customer’s situation. Computers in Network A simulated corporate headquarters sitting behind SonicWALL A, and computers in Network B simulated the branch office sitting behind SonicWALL B. We configured Web servers A and B with a default.htm page that identified them and was used simply to demonstrate connectivity across networks.

In the lab, routers on both sides of the Internet were on the same network. That won’t be the case in your real world, where there are lots of routers to move traffic across the multiple networks of the Internet. To keep things simple in the lab, we only provided two. Routers A and B were simply Windows NT 4.0 standalone servers. They each had two network cards and, prior to the implementation of the SonicWALLs, were configured with static routes so traffic could be routed back and forth between Network A and Network B. We could have easily replaced these boxes with any hardware router, but the NT servers were more readily available and were easily configured.

As you might guess—and will later see—this type of arrangement can be used to test multiple firewall/VPN solutions as well as any type of test in which you need to simulate multiple real offices within the confines of a test lab. Sure, it’s best to do things real world, but your first tests are easier in one location where you can walk over and see how the other side is configured instead of relying on what someone 1,000 miles away is telling you.

In my case, before configuring and testing the VPN gateway, we performed a few simple connectivity tests. It makes no sense to jump right in and attempt to work with something new if the status of your network and its connectivity with others is unknown. If you do so, you may spend hours troubleshooting the “new” when your problem lies somewhere else.

Test 1: Network Connectivity
Without the SonicWALLs in place, we tested simple routing, i.e. can computers in Network A reach the Web server in Network B? Since no name resolution was established, we used the IP address of Web server B in our URL, and, as expected, computers in Network A could reach the Web server in Network B, and computers in Network B could reach the Web server in Network A. Routing was OK.

Test 2: Firewall Operation
We placed one firewall online. By placing only Firewall A online, we could establish that, yes, the firewall was correctly configured to allow access to, but not from, the Internet. We then implemented Network Address Translation (NAT) on the SonicWALLs. This meant a slight change to our routers, as they no longer would be routing directly between Network A and Network B, but between the WAN ports of the two SonicWALLs. In the first test, that would have been between Network B and the WAN port of SonicWALL A. In our case, computers in Network A could still reach Web server B, but computers in Network B could no longer reach Web server A. This was the expected behavior and confirmed that the firewall and NAT services were working.

Taking SonicWALL A offline and putting SonicWALL B online (and reconfiguring routing) allowed computers in Network B access to Web server A again, and, of course, blocked computers in Network A from Web server B. Placing both firewalls online prevented access to either Web site from opposite networks. A Web server on the network between both routers (not shown in the figure) could be seen by clients in either network, but couldn’t, on its own, access Web servers A or B. So routing, NAT and both firewalls appeared to be functioning.

Test 3: VPN—Oh, Really?
So here we were, the real purpose of our lab. With both SonicWALLs online, we needed to access the opposite network’s Web server across our simulated Internet. If Web servers A and B were meant to be public Web servers, and our only desire was to ensure access to these Web servers behind the firewall, then our approach would have been to simply publish these servers using the SonicWALL interface. Remember, though, that we were merely using these Web servers to demonstrate access to the network—not as public Web servers. We wanted to provide a safe way for employees at different locations to access the internal network of another office. They might need to access company mail servers, file servers and intranet servers. In short, we wanted to link two disparate networks and make them as if they were one—the exact definition of a VPN.

Figure 1 shows this “virtual” path via the dotted line that extends between the two firewalls. The “real” path, of course, is denoted by the solid line from SonicWALL A, through Router A, across the Internet, through Router B, to SonicWALL B.

Since our initial configuration included using SonicWALL SOHOs for which VPN support is optional, the instruction book doesn’t include directives. To enable VPN support (available on some models by default, on others as an option), we had to purchase—then enable—this function. Instructions for creating the gateway weren’t in the book, but were available on the SonicWALL Web site. Configuration for gateway-to-gateway VPN appeared straightforward. However, our path wasn’t.

As I’ve stated in previous articles, configuring IPSec in any interface isn’t easy; you have to know IPSec and you have to know how to interpret the interface. Implementing VPN gateways on SonicWALL isn’t an exception to that rule. In fact, in my experience, even a solid knowledge of IPSec and how to interpret the interface is no predictor of immediate success. Our first attempt in the lab was unsuccessful after five hours of work. (See, “It’s in the Firmware, Stupid” in the next section.) We were later able to demonstrate and implement this solution. The full details of configuring the SonicWALL firewall aren’t presented here—this is simply information necessary for filling out the SonicWALL VPN interface. This wasn’t the information I used at my client, nor is it recommended as a secure implementation—it’s just an example for test purposes.

1. The first decision you must make is the method used for VPN gateway authentication. There are two choices: Manual Key or IKE. You must decide between the two. To help you, I’ve included in “MIKE or IKE” some information about each—along with a rant about why neither is really a good solution. For our implementation, we chose IKE.
2. Next, Security Associations (SA) must be configured. SAs represent the connection and communication paths between two ends of an IPSec tunnel. Two SAs exist for every connection. To configure SAs in SonicWALL, you must fill in a simple arrangement of text boxes and drop-down lists. You must do so at each SonicWALL. Table 1 lists the elements and defines possible choices as well as our choices for both SonicWALLs.
3. Finally, you must click the Update button to apply the configuration to each Sonic Wall.
4. To test access to resources on the other side of the other SonicWALL, we entered the IP address-based URL for the opposite network’s Web site, like we had pre-VPN configuration. We were able to open the default Web page on the other side’s Web site.

It’s in the Firmware, Stupid
When we were struggling with proof-of-concept in our homegrown lab, we did try to find help from others. Our calls to SonicWALL for support didn’t produce a connection—or a callback. To be fair, SonicWALL does offer paid technical support, but we hadn’t purchased it. In addition, SonicWALL eventually fixed the problem and made the solution publicly available on its Web site.

Before this fix was available, we happened to find a tech from another company where SonicWALL was supposedly configured in this same manner. He looked at our configuration—even re-configured our setup from scratch—and couldn’t find any problems, nor could he make it work. Fortunately, this was a test lab and not a live installation.

What was the SonicWALL-provided solution? Was it some magical chanting? A misconfigured network? A misunderstanding? Some fairly obtuse setting? Did a SonicWALL-VPN guru ride to the rescue? Nope. ’Twas a new release of the firmware. Success assured, we were able to demonstrate the VPN and implement it.

This post-release “fix” of an advertised feature shouldn’t be considered unusual nor damnable. It’s the equivalent of getting a Microsoft hotfix or perhaps a service pack that magically fixes something that should have been working in the first place. In neither case is this the way things should be (shouldn’t we get what we pay for when we pay for it?), it’s just the way it is. Live with it or start your own company and provide IT software and/or hardware products. Come see me in a few years. Oh, and bring your perfect track record.