VPN connect a Netvanta to a SonicWall

[Anonymous]

I have been able to do this in the past but have forgotten what needs to be changed in order to get a VPN tunnel connected when using any Netvanta with any SonicWall device.  I know there is a need to Force nat traversal but not sure if it is V1 or V2 and whether to disable the other.  I currently have one vpn on this device back to another Netvanta and I can see negotiation and related vpn traffic for it but I do not see any VPN traffic for the new policy 101 I just created.  The Sonicwall can initiate a connection and bring the tunnel up but cant ping from the Netvanta side back to SonicWall.  I have included some of the config to see if it helps. Are there any restrictions on pre-shared key such as length or special characters?   Actually since Sonicwall nor Netvanta show any negotiation attempts coming from Netvnata I assume I have some issue on my side.  Any help is greatly appreciated.

crypto ike policy 100

  initiate aggressive

  respond anymode

  local-id address X.X.X.88

  peer X.X.X.68

  attribute 1

    encryption aes-256-cbc

    authentication pre-share

    group 5

    lifetime 3600

!

crypto ike policy 101

  initiate main

  respond anymode

  local-id address X.X.X.88

  nat-traversal v1 force

  nat-traversal v2 disable

  peer X.X.X.18

  attribute 1

    encryption 3des

    authentication pre-share

    group 2

!

crypto ike remote-id address X.X.X.68 preshared-key xxxxxxxxxx ike-policy 100 crypto map VPN 92 no-mode-config no-xauth

crypto ike remote-id address X.X,X.18 preshared-key xxxxxxxxxxxxxxx ike-policy 101 crypto map VPN 102 no-mode-config no-xauth nat-t v1 force nat-t v2 disable

!

crypto ipsec transform-set SECURE_TRANSFORM_SET esp-aes-256-cbc esp-sha-hmac

  mode tunnel

crypto ipsec transform-set esp-3des-esp-sha-hmac esp-3des esp-sha-hmac

  mode tunnel

!

crypto map VPN 92 ipsec-ike

  match address VPN_92_VPN_SELECTORS

  set peer X.X.X.68

  set transform-set SECURE_TRANSFORM_SET

  ike-policy 100

crypto map VPN 102 ipsec-ike

  description BoG

  match address VPN-102-vpn-selectors

  set peer X.X,X.18

  set transform-set esp-3des-esp-sha-hmac

  ike-policy 101

ip access-list extended VPN_92_VPN_SELECTORS

  permit ip host X.X.X.88  172.18.5.0 0.0.0.255     log

  permit ip 192.168.92.0 0.0.0.255  10.82.100.0 0.0.0.255     log

  permit ip 192.168.92.0 0.0.0.255  192.168.0.0 0.0.255.255     log

ip access-list extended VPN-102-vpn-selectors

  permit ip 192.168.92.0 0.0.0.255  10.82.1.0 0.0.0.255

ip policy-class Private

  allow list VPN_92_VPN_SELECTORS

  allow list VPN-102-vpn-selectors

  allow list self self

  nat source list wizard-ics interface eth 0/0 overload

!

ip policy-class Public

  allow reverse list VPN_92_VPN_SELECTORS stateless

  allow reverse list VPN-102-vpn-selectors

  allow list web-acl-3 self

[Anonymous · Accepted solution]

Edited by noor to include information about crypto ike policy:

@3l3mn8r - It has been our experience that when attempting to configure a VPN tunnel with a Sonicwall device, NAT-Traversal v1 be disabled and NAT-Traversal v2 be forced. Based on your configuration, it appears you may have that backwards:

crypto ike remote-id address X.X,X.18 preshared-key xxxxxxxxxxxxxxx ike-policy 101 crypto map VPN 102 no-mode-config no-xauth nat-t v1 force nat-t v2 disable

should be

crypto ike remote-id address X.X,X.18 preshared-key xxxxxxxxxxxxxxx ike-policy 101 crypto map VPN 102 no-mode-config no-xauth nat-t v1 disable nat-t v2 force

Also,

crypto ike policy 101

  initiate main

  respond anymode

  local-id address X.X.X.88

  nat-traversal v1 force

  nat-traversal v2 disable

  peer X.X.X.18

  attribute 1

    encryption 3des

    authentication pre-share

    group 2

should be

crypto ike policy 101

  initiate main

  respond anymode

  local-id address X.X.X.88

  nat-traversal v1 disable

  nat-traversal v2 force

  peer X.X.X.18

  attribute 1

    encryption 3des

    authentication pre-share

    group 2

The rest of your configuration looks good. The only thing you will want to verify is that the crypto map is applied to the WAN interface and that you have route(s) in place so that the VPN traffic is routed out the WAN interface (usually the default route will take care of this).

If you continue to have issues bringing the VPN tunnel up, it would be a good idea to capture VPN debug off the AOS device. You can do this by consoling, telnetting, or SSHing into the AOS device and enabling "debug crypto ike". It would be a good idea to increase your scrollback or log your output as this will display a lot of information. Once you enable the debug, you will want to attempt to bring up the tunnel.

I would be more than happy to review the debug output if you are still having issues. Please let us know if you have any further questions.

Thanks,

Noor

Message was edited by: noor

[Anonymous]

Thanks for this. I was having a similar issue and this post helped alot!

Jamie