Two days of work and a lot of stupid mistakes later, I finally set up a functioning "transparent" VPN between two facilities. By transparent, I am referring to the fact that the VPN will start on-demand and is transparent to the end users on each network being connected by the VPNs (no one has to manually initiate the VPN). Usually, my preference would be to simply use gear from the same manufacturer (i.e. SonicWall/SonicWall or Netgear/Netgear), but it made no sense to decommission two fully functioning routers because I was too blockheaded to get them to play nice with one another.
So, here is the setup: On end A, we have a SonicWall running SonicOS 4.2.x (advanced) with SonicROM 3.1.x. On end B, we have a Netgear FVS124G running the latest firmware, 1.1.48. Netgear has a great howto at VPN Between NETGEAR ProSafe VPN Firewalls and SonicWALL, but there are a few tiny gotchas that got me. The two primary issues were related to the Local and Peer IKE IDs and the destination networks. The screens on our SonicWall looked different. Instead of:

Our VPN Policy screen looks like:

Make sure that your Local and Remote IKE IPs are swapped on the Netgear (or other box) you are trying to connect to. (If your local IKE ID on the Netgear is 1.2.3.4, then the Remote (or Peer) ID on the SonicWall should be that number. (In many VPN examples out there (especially with Netgear), the local and remote IKE IDs are in the form of a FDQN, fully qualified domain name, which actually doesn't have to be a real FDQN. For example, thisismynetgearfdqn.com and thisismysonciwallfdqn.com will work respectively.
Then, the issue of how you define the local and remote networks on the SonicWall created a ton of problems. To make issues worse, the error logs gave no real indication that the problem was the definition of those networks. In my example, I wanted the SonicWall network of 10.1.1.0/24 (or 10.1.1.0/255.255.255.0) to be accessible by the people behind the Netgear network and vice versa.

At first, I defined the local network as Any Address. This meant that any addresses on the local network would have access to this VPN. Both of the Routers are dual-homed and in the case of the SonicWall, it is not only dual-homed, but it also manages two subnets. One subnet is for an internal, administrative network and the other is for guests of the company (aka the open network) to surf at their leisure. We don't want the open network clients to have access to anything but the internet. So, besides this potentially causing errors with the remote network definitions on the Netgear:

It also would (potentially) give guests access to the remote subnet. This is definitely not something we wanted. So, suffice it to say, one needs to be very, very careful as to how the local and remote networks are defined on the SonicWall. I defined a range of IP addresses for the remote network on the SonicWall, whereas on the Netgear, I had defined an entire subnet. Even though they technically matched (i.e. 10.0.0.1-10.0.0.255), this is not the same as defining a subnet in the Phase 2 portion of the handshake. So, if you define a subnet on the Netgear, then you must define the address range you wish to reach on the SonicWall as a subnet also.
The last gotcha came in the form of which interface the VPN was bound to. Because both routers were dual-homed, I had to make sure that the traffic for the VPN went through the fastest interface. On the Netgear, this was WAN2 and on the SonicWall this was interface X1. Here is a screenshot of the SonicWall:

This is where things get complicated and this HowTo/notes page really won't do justice to your setup. None of this matters if your routers are single-homed. In my case, not only was the dual-homing a complication, but, in the case of the SonicWall, I thought I had to bind the VPN policy to the internal subnet with which we were playing. That is wrong, you need to bind it to the external interface that is the endpoint of the VPN for the remote (in this case, the Netgear).
The last bit is just like in the Netgear KB article. The SonicWall Proposals tab looks like:

There are a few things we should recap. First, as the Netgear KB article implies, you really want to print this out and write in your own values. Here is the IKE Policy page from the Netgear:

It is very easy to mistake one IP for another and make the subnet versus IP range mistake I made on the SonicWall. The three gotchas are Local and Remote/Peer IKE IDs, defining the local and remote networks and, in the case of the SonicWall (and the complication of dual-homed devices), binding the VPN policy to the correct interface.
Hopefully some of my experiences have helped you with configuring something similar.
updated: 2010/07/14


