This Tech Tip is mostly obsolete: we've since written a replacement Tech Tip that shows the superior IKE/shared secrets method of configuration, and it replaces the manual key method described here. But we'll leave this one here for posterity.

This tech note reflects our experience creating an IPSec VPN between a Netopia R9100 router and the Sonicwall Pro (and Pro-VX) internet firewall appliance. We hope it will save you the time that we have put in on this.

• Tech Tip: Dynamic Netopia-to-Sonicwall IPSec VPN with IKE

Background

We have long used Netopia and Sonicwall products at our own and at customer networks, and as such have learned them moderately well.

Netopia R9100 Ethernet-to-Ethernet Router - This is a low-cost (around $400 street price) that has an Ethernet port on one side and an eight-port hub on the other side. There are quite a few units in the R series, but this one is our preference because the Ethernet port on the "outside" provides more flexibility than those with (say) DSL interfaces.

They support IPSec and a great deal more flexibility in configuring the finer points of NAT, and w have used them as VPN boxes as well as on DSL and cable modem circuits. Though these are more expensive than cheaper units from (say) Linksys, we have found Netopia support to be so good that we're more than willing to pay for a product with real engineering behind it.

Vendor product information can be found here.
Sonicwall Pro Security Appliance - These are mid-range firewalls that perform stateful inspection and have a very good web-based configuration system. In addition to the obvious "inside" and "outside" Ethernet ports, there is a third "DMZ" port that is used for parking public web and mail servers in a way that minimizes the exposure should one of them be compromised. These units support IPSec VPNs and come with varying numbers of supported clients. They recently introduced failover support, where a pair of Sonicwalls can work in parallel, with a backup unit taking over should the primary fail. A customer has done this and it seems to work pretty well.

The Sonicwall Pro-VX is a high-performance version of the Pro, and it has a street price of around $3500. Vendor product information can be found here.

Environment Described

All configurations are with the Netopia R9100 (with 4.8.2 firmware) on a home DSL circuit making outbound connections to Sonicwall units (w/ 6.0.0 firmware) at customer locations. We know this also works with Netopia 4.8.3 firmware, and suspect it works with pretty much any R-series router. At no time does the Sonicwall initiate a connection to the Netopia.

Our main configuration uses NAT through the IPSec tunnel, so that we can reach the customer's systems easily but reverse traffic is not allowed. We have lots of customers and cannot permit intermixing of their packets. Sorry. Running NAT also simplifies the remote routing because responses back to the Netopia side need only know about a single IP address.

We must be clear that these instructions all assume that both routers are already working correctly in their "normal" firewall modes, and that these instructions are only for the VPN setup. We don't care to describe out-of-the-box configuration. We also presume that you know about networks in general.

Sample Network Assumptions

There are three IP addresses or networks involved in a VPN, and we'll describe our examples here.

Target Network: This is the full network that we're ultimately trying to get to, and it's usually a private address range such as 10.x.x.x. The remote network is behind the Sonicwall on the other end, and we cannot ever get to this network directly. We wish to be on this network as if we were directly attached, and for our example we will use 10.1.0.0/16. This is a class B address with 64k hosts.
Gateway Address: This is the "public" IP address of the IPSec interface, and it's the address of the Sonicwall itself. We don't really have very many good ideas for an example, so for no good reason we'll pick 167.216.147.218.
Local Network: This is the IP address of the local workstation that is behind the R9100. A reasonable custom for networks behind a Netopia is to also use one of the private addresses, so for our example we will use 192.168.1.0/24, with the Netopia's inside address being 192.168.1.1.

Netopia configuration

Create a new connection profile for this VPN tunnel. Select "WAN Configuration", then "Add Connection Profile", and you'll be given a screen that looks like this. Our changes are shown in bold with commentary in italics.

                         Add Connection Profile

         Profile Name:                      My.Customer     pick your own name
         Profile Enabled:                   Yes

         Data Link Encapsulation...         IPSec
         Data Link Options...               see below

         IP Enabled:                        Yes
         IP Profile Parameters...           see below

         IPX Enabled:                       No              Ewww yuck

         Interface Group...                 Primary

         COMMIT                             CANCEL

The Data Link Options item brings up the next screen, which allows for entering of the encryption and authorization keys. It appears that Netopia only supports manual keying mode, not the shared secret mode that's also supported by the Sonicwall and others. This seems really inconvenient, though we've not done it any other way to have firsthand experience with it.

                  IPsec Encryption & Authentication Options


         Encryption Transform...            DES                  or maybe 3DES
         Encryption Key:                    ******************** 16 hex bytes


         Authentication Type...             ESP
         Authentication Transform...        HMAC-MD5-96
         Authentication Key:      ******************************** 32 hex bytes

                 COMMIT                     CANCEL

Note: Only Netopia units with the optional VPN accelerator card will show 3DES as an option, but we don't have one of those yet so can only do 56-bit DES. Those with experience are encouraged to let us know.

The two encryption keys are both long strings of hex digits, and these will be entered here and again later in the Sonicwall. We have observed that the Sonicwall permits longer strings than does the Netopia -- perhaps due to the 3DES support -- but it seems happy to take the 16 and 32-digit strings we enter here.

We typically enter passwords and keys like this into the excellent and free program Password Safe from Counterpane Labs, and use the Windows cut/paste operations. This is especially helpful with long strings of hex digits, though it requires special steps to work with the Netopia. Normally one telnets to the inside interface of the router, but pasting large strings simply doesn't work properly (Netopia has been notified). Instead, telnet to the outside IP address and it should behave correctly.

Enter these changes with COMMIT to return to the main connection-profile screen, then select the "IP Profile Parameters..." menu. This sets up all the options related to the IP address, and we have hammered out the details only by doing this a lot.

                          IP Profile Options

         SPI (Security Parameters Index):   20000                 in decimal

         Remote Tunnel Endpoint Address:    167.216.147.218       Sonicwall outside IP

         Remote Members Network:            10.1.0.0              Sonicwall inside network
         Remote Members Mask:               255.255.0.0

         Address Translation Enabled:       Yes
         NAT Map List...                    Easy-PAT
         NAT Server List...                 <<None>>
         PAT IP Address:                    192.168.1.1           Netopia inside IP

         Filter Set...                      <<None>>
         Remove Filter Set

         Advanced IP Profile Options...

                 COMMIT                     CANCEL

The SPI (Security Parameters Index) is a number that seems to select this entire set of parameters for IPSec, and we believe it's needed because it's possible to have more than one tunnel described between any given pair of networks (different encryption, etc.), and the SPI selects the list of parameters that you actually want. It's actually possible to set a different SPI for the incoming and outgoing connections, but we don't need that.

SPI must be unique across the entire VPN base, and this means that the consultant talking to multiple unrelated customers have to plan carefully. We believe that we can't use SPI (say) 1234 for one customer and then the same SPI for a different connection to a different customer. But we're not sure. The SPI entered in the Netopia is in decimal, and SPI from 1-255 are supposed to be reserved for other purposes. The Sonicwall takes the SPI in hex but doesn't make this obvious, so keep this in mind.

The "Remote Tunnel Endpoint Address" is the outside LAN IP address of the remote SonicWall, and this is always the public, routable IP address.

The "Remote Members Network" and "... Netmask" reflect the INSIDE address of the Sonicwall LAN, and it's the 10.1.0.0/16 network that is protected by the firewall.

We typically enable "Address Translation" because it permits a one-way connection to the remote network, and this makes for a much easier routing on the other end. If we are routing a full network (anything more than one IP address), then the Sonicwall must be told about it. By using a single IP, routing is a non-issue.

We'll touch on the "NAP Map List" and "NAT Server List" shortly, but the "PAT IP Address" must be the Netopia's inside IP address. This is in contrast to the default value of 0.0.0.0, which is the outside address of the Netopia, and this default causes no end of trouble. We very much wish we had found this much earlier in the process.

Strictly speaking, setting up of NAT is supposed to be part of the basic Netopia configuration, but the value of Easy-PAT is normally created by the router by default, and it essentially hides the entire inside network behind a single external IP address. Adding a "NAT Server List" allows for very limited reverse traffic from the remote network back to the local, such as a web server or secure shell. We don't normally enable this.

Setting up the Sonicwall

Setting this up on the Sonicwall is much easier. First use a web browser and login to the firewall as the administrator. This presents a set of menus with the tabs on the left. Click the VPN button on the left, which brings up a multi-tabbed set of panels. Click on the Configure tab at the top, then configure this screen per this image:

We'll note a few items:

Important Settings
Setting	Description
Security Association	-Add New SA- - this allows addition of a new security association as opposed to modifying the old one.
IPSec Keying Mode	Manual Key -- this sets the manual key mode with long hex strings, as opposed to the "pre-shared secret" mode.
Name	This is a printable name for the connection
Disable This SA	This box may be checked to temporarily disable this Security Association (as opposed to deleting it entirely). Don't check this box.
IPSec Remote Gateway	Leave this blank. This field is only used when the Sonicwall is making an outbound VPN connection, but in our configuration it'll only be accepting inbound connections.
Enable Windows Networking	We generally leave this unchecked, but we suspect that for connections that will heavily use Windows broadcast for NETBIOS name resolution it must be checked. Experiment as required, but it most likely doesn't affect base TCP/IP connectivity.
Incoming SPI	This is the same value as the SPI programmed into the Netopia, and it must be in hexadecimal. It's regrettable that there is no obvious indication of this requirement, as it caused us to burn a lot of time.
Outgoing SPI	We typically make this the same as the Incoming SPI, but since the Sonicwall is not making outbound connections, it's probably not needed.
Encryption Method	This must match the Netopia configuration, which is Encrypt and Authenticate (ESP DES HMAC MD5).
Encryption Key	This must be the same 16-character hex value programmed into the Netopia. The default value is an apparently random 48-character value that is appropriate for 3DES, but we replace it with our value.
Authentication Key	This is the same 32-character hex value as entered into the Netopia for the same purpose.
Destination Networks	Since the source of this VPN -- the Netopia -- is using a single IP address via NAT, we need not enter any local network information. But if NAT is not used, the entire local network (on the Netopia side) must be described here.

Once this information is entered, click Update to make this information take effect. This should not require a reboot of the Sonicwall, and back on the Netopia side, simply try to connect with a machine on the remote network. This should bring up the VPN after a few seconds and start the connection.

Troubleshooting

In practice, we usually set up the Sonicwall first, because the random keys that get filled in by default seem random enough to us. We typically trim the 48-character encryption key down to 16 characters, then cut from the browser and paste into Password Safe. This makes it easier to be sure that we've not misrecorded the hex keys. Once the Sonicwall is set up, we start with the Netopia and use our saved keys.

more to be filled in here

More Tech Tips

Does this site look plain?