Connecting 9620L to IP Office behind Sonicwall 1

[jhengel]

All of my IP Office VPN experience is with Cisco ASA's and I love this combo (never had a single problem). I am however stuck in a situation where we do not have control of the firewall at a current customer's site, and am trying to get two 9620s connected to an 8.0.43 IP Office behind a Sonicwall.

Here are the settings as I have them entered in the 9620 per the Sonicwall technician.

Page: General Settings
VPN: Enabled
Gateway Address: (intentionally left blank)
Encapsulation: 4500-4500
Copy TOS: No

Page: Authorization Type
Authorization Type: PSK

Page: IKE PSK
IKE ID (Group Name): VPN Phones Connection
Pre-Shared Key (PSK): (Intentionally Left Blank)

Page: IKE Phase 1
IKE IT Type: FQDN
IKE Xchg Mode: Aggressive
IKE DH Group: 2
IKE Encryption Alg: 3DES
IKE Auth Alg: SHA-1
IKE Config. Mode: Disabled

Page: IKE Phase 2
IPSec PFS DH Group: 2
IPsec Encrpytion Alg: 3DES
IPsec Auth. Alg: SHA-1
Protected Network: 0.0.0.0/0

Page: IKE Over TCP
IKE Over TCP: Never

I recieved a screenshot from the technician working on the sonicwall for these two pages only but here they are.

The phone flashes passed the public IP address of the sonicwall in a hurry but fails IKE Phase 1 after about 15 seconds of trying to exchange keys with no response. It is an open port issue? All help would be greatly appreciated as I am very in the dark in terms of how sonicwall's are programmed and function. The "site to site" under policy seemed odd to me as well.

 

[jhengel]

By the way - I also created an IP Route in the IP Office with the following:

IP Address: 0.0.0.0
IP Mask: 255.255.255.0
Gateway IP Address: 192.168.1.1

 

[amriddle01]

That route is wrong, needs to be 0.0.0.0 as the mask not 255.255.255.0, using 255.255.255.0 means only send traffic from networks that actually start 0.0.0 and that is not possible

 

[bdelmar]

make sure "Enable H.323. Transformations" is turned off.

 

[jhengel]

Hmm - thanks amriddle, I knew that and not sure what I was thinking. Fixed, however the same problem is still occuring.

I had the sonicwall technician from the other company watch the logs as the phone created the tunnel. It tried to exchange keys for 15 seconds before failing during which time he said he got an error saying IKE ID mismatch. He wanted to simplify the name of the group so we changed that to simply be "VPN" however the same error popped on the Sonicwall.

I noticed on his screenshot that he has the policy type set as site-to-site, which if I am not mistaken is incorrect as it should be a tunneling protocol, not a site to site vpn. I had him change this option and the problem has still persisted with the same error.

After a bit of digging - I am a bit curious, as again - I have never been inside a Sonicwall. Do you HAVE to use the "WAN GroupVPN" IKE or can you create a new group to simply handle only VoIP clients and set permissions on this group seperately from others.

Any help would be GREATLY appreciated, I need to get this phone tunneled then shipped to Florida ASAP!

Thanks!

 

[littlejon]

jhengle,
Are you using the 96xx as a VPN phone, or just another IP Phone which happens to be located at a different site that's caonnect via Site-to-Site VPN connection.
SonicWall is not the "friendliest" when it comes to VPN Phones and the fact that the default name is (i believe) something like "Group VPN". You can't put the space in phone's config when setting it up unless you're using a script.
If this is a Site-to-Site, can the computers ping a device on the opposite site? If so, you may want to use the phones as "straight" IP Phones, making sure you have the IP Address of the Call Server set.

 

[jhengel]

Thank you for the response littlejon.

After 3 hours of learning SonicWall's GUI over screenshots from the internet we developed a successful tunnel! I will touch on a few of the responses here and what the final outcome was to hopefully help everyone fight this demon in the future.

The ISP who had configured the SonicWall for our phone customer was using the Sonicwall in standard mode and not advanced mode like they had told me (which they assumed) over 3 times. Please remember not to trust anything that isn't programmed by yourself

Because of this, the IKE ID was GroupVPN (case sensitive) instead of WAN GroupVPN. I am a little unclear on how the programming actually works on the Sonicwall, but he said the default was "WAN GroupVPN" despite being in standard mode. He also claimed that his configuration showed our tunnel was connected through "Wan GroupVPN".

Despite all of this - using the IKE ID - "GroupVPN" on the 9620L proved to bring a solid connection.

Here are the final phone settings I used:

-Be sure to set "Addr" tab settings to what your phone would use as if it were on-site.

*VPN Page under CRAFT menu*
VPN Vendor: Other
Gateway Address: Sonicwall Static IP Address
External Phone IP: 0.0.0.0 (Or Static)
External Router: 0.0.0.0 (Or Static)
External Subnet: 0.0.0.0 (Or Static)
External DNS: 0.0.0.0 (Or Static)
Encapsulation: 4500-4500
Copy TOS: No

AUTH. TYPE
Auth Type: PSK

IKE PSK
IKE ID: GroupVPN
PSK: (Matches the Sonicwall's "GroupVPN" shared secret

IKE PHASE 1
IKE ID: FQDN
IKE Xchg Mode: Aggressive
IKE DH Group – 2
IKE Encryption Alg: Any
IKE Auth. Alg. Any
Ike Config Mode: Disabled


IKE Phase 2
IPSec PFS DH Group: 2
IPSec Encryption Alg: Any
IPSec Auth Alg. Any
Protected Network: (Example: 192.168.1.0/24)


IKE Over TCP
Ike Over TCP: Auto


On the firewall side - the technician used 3DES and SHA-1 for Encryption & Authentication. These settings successfully connected a 9620L running on 8.0.43 and a SonicWall TZ210W

 

[jhengel]

By the way - on the Sonicwall side of things:

I asked the technician to simply follow tech tip 190 for what he was doing. The configuration pages from what I can tell are not much different between the TZ120 and the TZ210W.