Dynamic Netopia-to-Sonicwall IPSec VPN using IKE

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 to Steve.

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 6.4.2.0 firmware. Netopia firmware 4.10 does not work with this configuration.

Sonicwall Configuration

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.
Name: 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.
Exchange: 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.
It's likely that Main Mode would work fine as well, as long as all the parties agreed on it.
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.
Shared Secret: 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 Update

Advanced Settings

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. We believe it incurs extra overhead that we didn't care for, so we've disabled it. This can be any setting as long as all parties agree.
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.

Netopia Configuration

We'll start with the "IKE Phase 1 Configuration", which specifies the shared secret to be used by one or more profiles:

Main Menu
»» WAN Configuration...
»» IKE Phase 1 Configuration...
»» Add IDE Phase 1 Profile...

Profile Name: This is a string used for local display purposes only - it's used when selcting 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.
Mode...: 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.
Shared Secret: This secret phrase must exactly match the phrase entered on the Sonicwall.
Diffie-Hellman Group: We're using Group 1, but any group works as long as all parties agree

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 Security Association.

Main Menu
»» WAN Configuration...
»» Add Connection Profile...

The Profile name is for display only and need not match anything on the Sonicwall.

Encapsulation Options This screen lets you choose IKE (as opposed to Manual Key) and the IKE Phase 1 Profile that contains the shared secret. Select them here:

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.

Troubleshooting

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.

Navigate: More Tech Tips