Security Advisor

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.

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.

Firewall test
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.
Table 1. The Security Association choices available for SonicWALL-based VPN.
Item Definition A B
Descriptive Name Chosen by engineer ANetwork BNetwork
IPSec Gateway Address The WAN address of the other SonicWALL. 208.156.183.52 208.156.185.62
Require XAUTH/RADIUS Requires RADIUS for authentication. Not supported for gateway-to-gateway. -blank- -blank-
Enable Windows Networking (NetBIOS) broadcase Allow browsing across the networks. Since this is a dangerous exposure-we left this unchecked. Unchecked Unchecked
SA Life Time (sec) The number of seconds before renegotiation of the SA. For testing purposes, we left this at the default. In the real world you adjust this figure. A shorter lifetime means better security. Should an attacker somehow figure out the keys, he or she only has access until the keys change. However, shortening the key lifetime further stresses the processor and potentially degrades performance as more calculations must be made. 28,800 28,800
Encryption Method Type of encryption to be used, including the choice of no encryption or tunnel mode only. While tunnel mode affords no protection, it's good for testing. Other possibilities include 56-bit DES, ARCFour, 3DES, DES or 3DES and MD5 (for integrity), Encrypt for Checkpoint, and simple MD5 for integrity. Once again, the more secure the algorithm, the more demands placed on the processor. Both sides must match. DES DES
Shared Secret Four to 128 case-sensitive characters entered by the engineer-both sides must match. A longer secret potentially will be more secure. For testing purposes, a small size makes it easier to eliminate simple typing errors as causes for failure. Since the shared secret must be the same on both sides, you want to make sure it's correctly entered. C12345 C12345
Add Network This button brings up a screen in which to indicate the destination network addresses. Network: 192.168.7.0 Network: 192.168.6.0

 

MIKE or IKE

The security of your VPN implementation hinges on the mutual authentication of each gateway. Each gateway should be required to prove that it actually is the SonicWALL you’ve approved to connect to your network. If some attacker could negotiate a connection with your VPN gateway, you’ve just successfully tunneled his attack right through your firewall and into your network. So it makes good sense to pick the most secure method of gateway-to-gateway authentication. Manual key (the “MIKE” above, or Manual Internet Key Exchange—an acronym made up by me), of course, is easier, but means that the keys used for encryption (and authentication, should you choose to implement this feature) are typed into the interface at both gateways. This means less security. Anyone who can observe the interface can see the key. To be sure, the keys are either 16- or 48-character hexadecimal keys and thus not easily remembered from casual observation; still, it’s not the best security. You must also manually enter the Security Parameters Indexes (SPI). The SPI, you’ll recall, is the identifier used by IPSec to determine which Security Association (SA) each packet is part of. IPSec usually generates these numbers (an ingoing and outgoing one for each SA). Any time something is manually entered that should be generated, there’s cause for concern.

IKE, or Internet Key Exchange, should be safer. After all, in this methodology, the encryption and authentication keys to be used by the IPSec protocol are negotiated at tunnel connection time. The methodology used to authenticate the two gateways is left up to the implementation, but methods like Kerberos or certificates are considered to be secure, while shared secrets—or words typed in the interface—aren’t. However, in the SonicWALL implementation, a shared key and IP address, or a unique firewall identifier (an alphanumeric name entered by the installer and used when the SonicWALL WAN IP address is dynamic) is used. All of these pieces of information are readily available to anyone who can read the SonicWALL interface, and, of course, have to be communicated between engineers responsible for setting up the devices.

Neither possible configuration offers really good security since it’s based on humans keeping their knowledge secret and limiting the exposure of the interface. In a small company, the risk may be less, as fewer people have knowledge of the secret. It can also be higher, since there may be less sophisticated knowledge of security. In our case where one trusted individual would have the information and was sworn in (in a blood-exchanging secret ceremony to keep the information confidential), the risk was acceptable.

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.

Additional Information

Besides the excellent April 2001 MCP Magazine cover story, “Private and Secure: The VPN Solution,” by Anil Desai on building a VPN, you can find an overview on Microsoft’s Web site at www.microsoft.com/windows2000/
techinfo/howitworks/communications/remoteaccess/vpnoverview.asp
. It’s a 281K compressed download. SonicWALL also provides documents at www.SonicWALL.com/vpn-center/vpn-setup.html#white-papers.

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.

comments powered by Disqus

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.