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
- 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
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
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
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
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
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
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
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
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
- 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.
- 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.
- Finally, you must click the Update button
to apply the configuration to each Sonic Wall.
- 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
||Chosen by engineer
|IPSec Gateway Address
||The WAN address of the other SonicWALL.
||Requires RADIUS for authentication. Not
supported for gateway-to-gateway.
|Enable Windows Networking (NetBIOS) broadcase
||Allow browsing across the networks. Since
this is a dangerous exposure-we left this
|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.
||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.
||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.
||This button brings up a screen in which
to indicate the destination network addresses.
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
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.
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
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