SonicWall to IOS Router VPN

Hello all,

I do use a Cisco 1760 with VPN module for IPSec VPNs handling site to site VPN with both endpoints using a static permanent IP address, but also Cisco VPN clients where the client IP address es dynamic (ISP assigned).

Most of the site to site VPNs are Cisco based, althought one of them is getting me crazy as there is no way of setting it with a Soniwall.

The isakmp and IPSec phases looks like established on the Cisco side, but when we send site to site traffic, the connection drops down and renegociates phase 1 and 2.

Can anybody give me a feedback of a working config for this VPN ?

SonicWall has a pdf with a configuration example, but it does not work. They do not inform on the versions used on both sites.

Regards

Jaime

Reply to
Jaime
Loading thread data ...

In article , Jaime wrote: :I do use a Cisco 1760 with VPN module

:Most of the site to site VPNs are Cisco based, althought one of them is :getting me crazy as there is no way of setting it with a Soniwall.

:The isakmp and IPSec phases looks like established on the Cisco side, but :when we send site to site traffic, the connection drops down and :renegociates phase 1 and 2.

- Check the syslogs carefully and ensure that there are no complaints about routes not being available.

- turn on nat-traversal on both sides if you have not done so already

- ensure that the transform set for both sides is very similar. In particular, there can be VPN problems if one end requests AH, the other end does -not- request AH, and there is NAT in the middle. In that situation, the negotiations can sometimes get through (the non-nat'd side tells the other side to go ahead with AH) but real traffic doesnt' work (because the AH that then gets sent gets NAT'd.) This is more of a problem if nat-traversal -is- turned on: without nat-traversal but with AH on, negotiations are more likely to get stuck than to get all the way through.

- Check the ipsec SA's on the 1700 and ensure that you are getting SA's for the connection. If not, then turn on crypto debugging on the 1700 and see at what point the negotiations fail. If one end is negotiating okay but the other end is not and is then tearing down the SAs, then you the final leg of the negotiations isn't making it back. This can be a routing problem (as mentioned before), or it can be a very subtle problem with overlapping crypto match address ACLs (especially if the remote peer IP for one side happens to be an IP covered by one of the other ACLs.)

Reply to
Walter Roberson

I have tons of Sonicwall to Cisco IOS VPN sites at my company. Which config did you need? Sonicwall or Cisco?

BTW, I have had problems with 3DES for Phase II for Sonicwall to Cisco. 3DES for phase I works fine. I have to use single DES on phase II. This appears to be a Cisco problem, as my Sonicwalls can talk to each other fine at 3DES.

-Bob

Reply to
Bob

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.