This site uses advanced css techniques
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.
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.
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.
There are three IP addresses or networks involved in a VPN, and we'll describe our examples here.
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: 22.214.171.124 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 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:
|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.
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