IKE ID Mismatch on Sonicwall VPN

sonicwall nsa 240 300x72 IKE ID Mismatch on Sonicwall VPN

Our company recently replaced a Sonicwall 2040 Pro with a Sonicwall NSA 240.  Configuring the new Sonicwall went reasonably smoothly with the exception of one of our site t0 site VPN Links.  When attempting to create a site to site VPN link to a Sonicwall TZ170 behind a Clear (Clearwire) wireless internet modem. It would receive the error: IKE Responder: Proposed IKE ID mismatch.  A summary of the configuration and steps to resolve the issue include:

  • Remote firewall is connected to the internet using Clear wireless network.
  • The Clear box has a static IP adress assigned to it.  All traffic is routed to an internal IP address on the Clear box.
  • The WAN port on the remote Sonicwall firewall (Sonicwall TZ170) is set to DHCP with NAT. The WAN port gets it’s IP address from the Clear box.

VPN Connections are setup as follows:

  • Policy Type:  Site to Site
  • Authentication Method: IKE using Preshared Secret
  • Name: Use the Unique Firewall Identifier.
  • IPsec Primary Gateway (on headquarters NSA 240 VPN): 75.X.X.X (the static IP address of the Clear modem at the remote office.
  • Local IKE ID on NSA 240: SonicWALL Identifier:  (The Unique Firewall Identifier on the NSA 240)
  • Peer IKE ID on NSA 240:  SonicWALL Identifier: (The Unique Firewall Identifier on the TZ170)
  • NOTE:  The previous 2 steps are critical for it to work properly.
  • On your Proposal settings use your personal preferences but make sure the Exchange for IKE (Phase 1) Proposal is set to Aggressive Mode.

We were only able to successfully create the VPN link by using the correct Unique Firewall Identifier names, properly setting the Local and PEER IKE ID and setting the Exchange to Aggressive Mode.

3 comments for “IKE ID Mismatch on Sonicwall VPN

  1. Sven Celis
    November 30, 2011 at 11:29 am

    Thankssss mate!!! This really is the way to go! I just had the same problem with a customer us in Belgium. The ISP wouldn’t give any of our devices a public IP-address. Our sonicwall always has an IP-address in the private range (192.168.254.2). A full NAT was active to this WAN-port.

    I just followed your instructions and bingo!! A few seconds later, the VPN-tunnel would come up. In the logs I could see that the firewall was responding with his private IP-address while the other firewall was pointing to it’s public IP-address.

    Thanks!!!

  2. PAUL MCCABE
    February 7, 2014 at 8:22 am

    THANKS MATE THIS WAS A GREAT HELP TO ME AS I WAS ONSITE AND COULD NOT GET IT WORKING UNTILL I READ THIS AND BANG, IT WORKED GREAT.

    THANKS AGAIN

  3. February 17, 2014 at 1:06 pm

    Thank you SO MUCH for this info. Thanks to you, I can now successfully run Site-to-Site VPN’s on a SonicWall TZ-180 connected behind an Apple AirPort Extreme wireless router. Prior to finding you, I had unsuccessfully tried a myriad of Sonicwall settings, plus futzing with Port Forwarding of UDP Ports 500 & 4500, and “Default Host” (which is Apple’s version of DMZ,) on the AirPort. Turns out that no settings needed changing on the AirPort. Just set up the Site to Site using your instructions above, and boom. Set up my Address Objects on the SonicWall as I normally do for other sites, and done. Now I get to have my full testing environment with multiple site-to-site VPN’s and I do not interfere with the AirPort LAN/WLAN. (When I originally tried placing the Airport into Bridged Mode behind the Sonicwall, network performance was terrible for some reason.) Nonetheless, I am all good now. Apple Airport network great. Sonicwall great. S2S VPN’s great. Thank you SO MUCH!!

Leave a Reply

Your email address will not be published. Required fields are marked *


*

Subscribe without commenting