Site-to-site Cisco IOS to SonicWall Pro 4100 failing

tom_parker · ‎12-16-2008

I am trying to setup a site-to-site VPN with a customer in another state but the tunnel never makes it through phase 1. I I have two other tunnels on this router, one to a Concentrator 3000 and the other to another Cisco router, and they both work fine.

The debug output (which I've attached) shows the following:

received packet from 172.16.3.1 dport 500 sport 500 Global (N) NEW SA

172.16.3.1 is the private network on the other side of the tunnel. Shouldn't this be the public side of the SonicWall device? I don't have access to the other end and am having to work via phone and chat. The person at the other end is working with SonicWall to debug their end. I wanted to make sure the my end was correct.

On our side, the tunnel is terminated on a Cisco 1841 router running 12.4(3g). The other end is terminated on a SonicWall Pro 4100 that sits behind a router.

Thanks for any help.

Tom

Jon Marshall · ‎12-16-2008

Tom

"172.16.3.1 is the private network on the other side of the tunnel. Shouldn't this be the public side of the SonicWall device?"

Yes you should be seeing the peer address rather than 172.16.3.1. The peer address as you say should be a publically routable address on the Internet.

Are you sure they are trying to create a site-to-site VPN and are not just letting clients from within their LAN run a remote access vpn from their desktops ? Can't think of another reason why you would be seeing that address.

Jon

mike_guy29 · ‎12-16-2008

The only reason I could think maybe you are seeing there internal IP as the source of the ISAKMP packets is if they are peforming some NAT on their side. e.g. their "public" interface has 172.16.3.1 as its IP which is then translated to a public IP address by an upstream device. All though the packets IP address would be changed and it would be routed over the Internet, the sonic wall may be populating fields in the packet with that IP address.

I had a similar thing once the other way round where a Cisco device was sat behind a NAT device and being translated. The sonic wall was then seeing the unnatted address (as I say I presume its populating in a field somewhere in the ISAKMP exchange)

I would get them to confirm that on their end and just check that none of the settings such as the local and remote IKE IP addresses are set to the private one.

Hope that helps

Thanks

tom_parker · ‎12-16-2008

I really appreciate the responses. I'll get them to check their configurations.

tom_parker · ‎12-23-2008

We've made some adjustments and I'm now getting this when I issue the show crypto isakmp sa command:

dst src state conn-id slot status

d.d.d.d s.s.s.s MM_NO_STATE 0 0 ACTIVE

I've looked it up and it seems that everything points to a configuration mismatch now.

I must be missing something because I don' see it. I've attached the current configs for both devices as well as a capture of the debug output while the SDM tested the tunnel.

Thanks for your help.

ajagadee · ‎12-23-2008

Tom,

From the debugs, it looks like the router is transmitting Phase 1 Packets and never seeing a response. This basically means, ISAKMP ports are blocked somewhere. That is UDP Port 500.

Can you make sure that the below ports and protocols are open between the Router and Sonicwall.

ISAKMP - UDP 500

ESP - Protocol 50

ISAKMP NAT-Traversal - UDP 4500 (NAT-T)

Regards,

Arul

*Pls rate all helpful posts*