This week I was setting up a site-to-site VPN between a main office and a branch office. As typical, I try to do a little advanced problem mitigation and research before every project. And while a “simple” site-to-site is “generally” straightforward, I figured a little quick check wouldn’t hurt. After all, I did remember something funny about site-to-site VPNs on dissimilar Sonicwall devices. I was connecting a Sonicwall PRO 2040 to a TZ 170 SP.
After a quick review of the Sonicwall website, I confirmed my recollections. The key wasn’t so much as the hardware, except for the fact that you always want to make sure that your hardware has the latest firmware installed, but rather that one system was running the enhanced OS, while the other was running standard OS. The configurations are not identical, and there is a Sonicwall reccomended way for networking dissimilar OS editions.
Here is the link to the PDF documentation from Sonicwall: Sonicwall KB 5670
Another minor problem we ran into was during the authenticiaton phase 2. The problem was basically that on the remote-site that the subnet did not match the main-site. The main-site had a subnet of 172.29.100.0/24 (so it was CLASSLESS/CIDR). However when I configured the remote-site, I specified the main-site subnet as CLASS B, or 172.29.0.0/16 — and it caused an authentication Phase 2 error. No big deal, a quick double check of the settings, and a quick change on the remote-site to be CIDR/24 and we were good to go. Along that note there is a difference as far as Sonicwall is concerned between a subnet of 172.29.100.0/24 and a range of 172.29.100.1 – 172.29.100.254 – while they are functionally the same, they are technically difference and IP/SEC will fail to negotiate the tunnel.
Enjoy!September 2010 Update: This article was corrected upon discovery of a typographical error in the IP information above. Additionally we added the last sentence to further expound on the importance of the configuration matching identically.