We have previously written
how to connect a Netopia R-series router
to a Sonicwall using manual keys, but by painstaking research, Steve
Gardiner has succeeded in making a Netopia on a dynamic IP address connect
using IKE shared secrets. This was an enormous task, compounded by
a lack of information - or even wrong information - from Netopia
and Sonicwall tech support. Their approach has apparently been that
they don't support each other's products, so this left the hard work
This Tech Tip is a summation of his research, plus a bit of our own.
The instructions here were created between a Netopia R910 with
4.11.3 firmware talking to a Sonicwall PRO with 18.104.22.168 firmware.
Netopia firmware 4.10 does not work with this configuration.
We're also grateful to Jacco de Leeuw for his excellent feedback
that has substantially improved the security advice contained
The configuration on the Sonicwall need only be done one time: after
it's set up, all the remote clients will use the same configuration.
This makes key management much easier.
To get started, login to the Sonicwall via a browser,
click the VPN tab on the left, then the Configure tab at the top,
then select -Add New SA- from the drop-down box. We'll note
the important fill-in fields in this screen shot.
IPSec Keying Mode
- This should always be "IKE using Preshared Secret". Other modes
are Manual Keying (which we've described elsewhere), plus certificate
modes we've not investigated.
This turned out to be one of the big surprises: this is not just
a display name, but it must match the "Local Identity" string set up
in the Netopia. The field here takes spaces, but the Netopia doesn't
allow it, so pick something like RemoteOffices. This can be
properly entered in the Netopia.
IPSec Gateway Name or Address
- This Security Association is incoming only, so a value of 0.0.0.0
may be entered. The default is blank.
- This determines how the two ends negotiate their initial
parameters, and "Aggressive" mode does everything in three packets,
as opposed to six in "Main" mode. The Sonicwall seems to require
a gateway if Main Mode is used, and we believe this is what breaks
the connectivity of dynamic remote clients. By using Aggressive Mode,
the gateway can be unspecified.
We're taken to understand that Aggressive mode is less secure than Main
mode because it's susceptible to dictionary attacks, but we've not been
able to get Main mode working for dynamic clients (e.g., the Sonicwall
requires the IP address of the remote unless it's in Aggressive mode).
Phase 1 DH Group
- This determines the encryption level of the Diffie-Hellman
keys, and these are Group 1 (768 bits), Group 2 (1024 bits) or
Group 5 (1536 bits). Longer keys mean more security but longer
negotiations at connection setup. These must match on both end,
and we're using Group 1 in our example.
Group 2 is much more secure and is recommended.
- This is the key magic phrase that all the parties share to
make their connections. This should be as complex as possible,
with special characters and unguessable words. The Netopia has
a limit of 32 characters - that limit should be respected here too
(we don't know the Sonicwall's limit).
Add New Network
Each remote network that's to use this Security Association must be
explicitly mentioned here, and this is done by clicking the
Add New Network button. As many remote networks can be added
as needed, though for larger operations it may be easier to add
a single larger enclosing network that encompasses the smaller
remote subnets. We've done this here:
Click Advanced Settings to make a few adjustments on this
page as well:
Enable Keep Alive
This option appears to make the VPN more resilient
in the face of network disruptions.
Enable Perfect Forward Secrecy
This feature adds additional security by forcing keys to be
recalculated at certain times. Our examples have disabled it, but
we're enabling it going forward. In any case, both parties must
agree on this setting.
Phase 2 DH Group
This should match the value in the main page: we used Group 1.
Click OK on the Advanced Settings page, uncheck
Disable This SA on the main page, then click Update
to make this Security Association take effect. This should be
the last time we modify the Sonicwall configuration for the VPN.
We'll start with the "IKE Phase 1 Configuration", which specifies
the shared secret to be used by one or more profiles:
»» WAN Configuration...
»» IKE Phase 1 Configuration...
»» Add IDE Phase 1 Profile...
This is a string used for local display purposes only - it's used
when selecting this Phase 1 profile with the Security Association.
It's probably most helpful if the name reflects the remote network,
but this name is not sent over the network and doesn't have to match
anything on the Sonicwall. There is a 16-character limit on this field.
This is the initial key exchange mode, and this must match the
Sonicwall: we're using Aggressive.
Local Identity Type / Value
This has to match the security association name as found on the
Sonicwall - it appears to be some kind of key. Trial and error showed
that setting Host Name works, and the name - without spaces - must
match exactly on the Sonicwall.
This secret phrase must exactly match the phrase entered on the Sonicwall.
The default is des, but if the Netopia has the
optional hardware VPN accelerator, des3 is more secure.
The default is md5, but with
suggest strongly that sha1 is more secure.
We're using Group 1 in our examples, but we're using Group 2
for all new installations because it's more secure.
Navigate to ADD IKE PHASE 1 PROFILE and key ENTER.
Add new connection profile
Once the IKE information has been entered, it's time to add a new
»» WAN Configuration...
»» Add Connection Profile...
The Profile name is for display only and need not match anything
on the Sonicwall.
This screen lets you choose IKE (as opposed to Manual Key) and
the IKE Phase 1 Profile that contains the shared secret. Select
Navigate to the Advanced IPSec Options:
Type ESCAPE when finished to return to Tunnel Options, then
navigate to COMMIT to exit these screens. This returns to
the main Connection Profile screen. Navigate to the
IP Profile Parameters.
IP Profile Parameters
This section requires numerous IP address parameters, and there
are two broad settings: NAT or no NAT. NAT - Network Address
Translation - can be run through the tunnel, and this means
that the Netopia side can reach anybody on the Sonicwall side,
but it can't go the other way, and non-NAT is a simple routed
network that allows free-flowing traffic in either direction.
Remote Tunnel Endpoint
This is the IP address of the Sonicwall's outside interface
(the public IP). The Netopia sends all the VPN packets to this IP,
and if this is incorrect, not only will the VPN not work, but the
Sonicwall won't have any record of the attempts in the logfiles.
Remote Member Format / Address
This describes the inside network being protected by
the Sonicwall: the VPN allows access to this address space.
Local Member fields
These can be blank for NAT connections, but otherwise must
specify the local network. This should match the Netopia's
LAN settings. These settings must be in the Sonicwall's
"Add Additional Network" list.
Address Translation Enabled
As mentioned above: this is Yes or No.
PAT IP Address
Only if Address Translation is enabled, this must match
the Netopia's LAN Ethernet address - the default of 0.0.0.0 specifies
the outside IP address: we're at a loss to see how this could
possibly be useful in a VPN environment.
Sadly, this is a very difficult area because the logging normally done
by both units is either incomplete or non-obvious. While fooling with
one setting at a time, we've found case after case where the incorrect
parameter could have been mentioned or logged, but was not. We find
this maddening that such a standard facility as IPSec needs to be so
difficult to debug.
The first place we typically look is the Sonicwall's logfile. This
at least shows intermediate steps of the process.
We have found that rebooting the Netopia is rarely necessary while
debugging these issues. Instead, we disable the profile of interest,
wait a moment, and re-enable it, and this has always been sufficient
to get things moving. We've never had to reboot the Sonicwall either.
We have a report of this configuration also working with the Netopia
3366C-ENT (firmware 8.5) connected to Sonicwall SOHO3 (firmware