Cisco ASA 5510 Site to Site VPN with Sonicwall

[manjitriat]

I am trying to setup a VPN tunnel between a Cisco ASA 5510 (Version 8.2(2)) and Sonicwall TZ200. I got tunnel up and going and I am able to ping the Cisco ASA internal IP from the Sonicwall LAN but nothing else works. When I try to ping a host behind the Cisco ASA from the Sonicwall LAN I get the following message "Asymmetric NAT rules matched for forward and reverse flows; Connection for tcp src outside:10.20.10.x/xxxx dst inside:10.20.2.x/xxxx denied due to NAT reverse path failures" on the ASA

Googling the above error shows issues with version 8.3 and later which looked like the nat commands were changed but the ASA I am working on is still on 8.2 and the other common issue is not adding a NAT exemption. I have double-triple checked that I did add a NAT exception rule from the hosts on the cisco network to the hosts on the Sonicwall network. Seems like I have hit a road block so any help would be appreciated. Thanks

Here are some excertps from the config file (10.20.2.0 behind the cisco and 10.20.10.0 behind the sonicwall)

nat (inside) 0 access-list nonat

..

access-list nonat extended permit ip 10.20.2.0 255.255.255.0 10.20.10.0 255.255.255.0

access-list outside_1_cryptomap extended permit ip 10.20.2.0 255.255.255.0 10.20.10.0 255.255.255.0

..

crypto map outside_map 1 match address outside_1_cryptomap

crypto map outside_map 1 set peer x.x.x.x

crypto map outside_map 1 set transform-set ESP-3DES-SHA

crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP

crypto map outside_map interface outside

..

crypto isakmp enable outside

crypto isakmp policy 5

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 28800

..

group-policy SiteToSitePolicy internal

group-policy SiteToSitePolicy attributes

vpn-idle-timeout none

vpn-tunnel-protocol IPSec

split-tunnel-network-list none

..

tunnel-group x.x.x.x type ipsec-l2l

tunnel-group x.x.x.x general-attributes

default-group-policy SiteToSitePolicy

tunnel-group x.x.x.x ipsec-attributes

pre-shared-key *****

..

Added few excerpts from config file

[josecalv]

Hi,

Could you provide your full NAT configuration? Forward some of the logs that you are seeing? What happens if you do a "clear local"?

Can you run a packet-tracer for the traffic flow that you are testing?

packet input inside tcp 10.20.3.20 1111 10.20.10.66 80

[manjitriat]

Thank you for the time Jose,

Let me first admit I am making most of the changes/configs using ASDM. Here is the NAT config

global (outside) 1 interface

nat (outside) 1 10.20.12.0 255.255.255.0

nat (inside) 0 access-list nonat

nat (inside) 1 0.0.0.0 0.0.0.0

nat (dmz) 1 0.0.0.0 0.0.0.0

10.20.12.0 - is the L2TP VPN DHCP pool

As for the logs I see a lot of other informational messages but that is the only one I see that pertains to the VPN. and here is the log that i see in detail

5          Nov 06 2011          22:52:32          305013          10.20.2.249          9100                              Asymmetric NAT rules matched for forward and reverse flows; Connection for tcp src outside:10.20.10.10/3727 dst inside:10.20.2.249/9100 denied due to NAT reverse path failure

I ran the Packet Tracer in ASDM and I think you meant the src ip to be 10.20.2.20:1111 to destination 10.20.10.66:80

and the result shows as "The packet is allowed"

[Julio Carvajal]

Hello Manjitriat,

Can you post the following commands:

-Show run route

Do a packet tracer and then give us:

-Show crypto Isakamp SA

-Show crypto Ipsec SA

Regards,

Julio

[manjitriat]

Hi Julio,

I finally figured out some of the issues. Running packet tracer showed the traffic going over VPN was getting NAT'd. The NAT exempt policy entered through ASDM does show up in the running config but they have no effect. I had to login through SSH and retype the exempt rule. I knew something was wrong since when I entered that command I didn't get a error saying the rule already exist.

Running the packet tracer again showed the VPN now getting exempt but it was getting blocked by an access rule even though I had entered a rule allowing IP traffic from 10.20.10.0 to 10.20.2.0 on the outside interface. So like before I logged into SSH and retyped the rule and didn't get an error saying the rule already exists. So I knew there was an issue and re-ran the packet tracer and the packets are showing passed through both (except for the one inbound as it says IPSEC spoof detected which I believe is normal).

What could I do next to figure out what the issue is?

[Julio Carvajal · Accepted solution]

Hello Manjitriat,

Ok, the IPSEC spoof detected is normal, it means that you are trying to send unencrypted packets over an encrypted line.

Now if you are seeing on the packet tracer that the traffic is going trough the VPN channel everything its fine in your site.

Now the packet tracer should be something like this:

packet-tracer input inside tcp private_ip_lan 1025 destination_private_ip_lan 80

Please provide us the output of the following statements after you run the packet tracer.

Show crypto Isakamp SA

Show crypto Ipsec SA

Regards,

Julio

[manjitriat]

Julio,

The packet tracer with the above settings shows the packet is allowed.

#Show crypto Isakmp SA

1  IKE Peer: y.y.y.y

    Type    : L2L             Role    : responder

    Rekey   : no              State   : MM_ACTIVE

#Show crypto ipsec SA

    Crypto map tag: SYSTEM_DEFAULT_CRYPTO_MAP, seq num: 65535, local addr: x.x.x.x

      local ident (addr/mask/prot/port): (10.20.2.0/255.255.255.0/0/0)

      remote ident (addr/mask/prot/port): (10.20.10.0/255.255.255.0/0/0)

      current_peer: y.y.y.y

      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4

      #pkts decaps: 44738, #pkts decrypt: 44741, #pkts verify: 44741

      #pkts compressed: 0, #pkts decompressed: 0

      #pkts not compressed: 4, #pkts comp failed: 0, #pkts decomp failed: 0

      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

      #send errors: 0, #recv errors: 0

      local crypto endpt.: x.x.x.x, remote crypto endpt.: y.y.y.y

      path mtu 1500, ipsec overhead 58, media mtu 1500

      current outbound spi: B486B4E8

      current inbound spi : 2E8B3062

    inbound esp sas:

      spi: 0x2E8B3062 (780873826)

         transform: esp-3des esp-sha-hmac no compression

         in use settings ={L2L, Tunnel, }

         slot: 0, conn_id: 50290688, crypto-map: SYSTEM_DEFAULT_CRYPTO_MAP

         sa timing: remaining key lifetime (sec): 19452

         IV size: 8 bytes

         replay detection support: Y

         Anti replay bitmap:

          0xFFFFFFFF 0xFFFFFFFF

    outbound esp sas:

      spi: 0xB486B4E8 (3028727016)

         transform: esp-3des esp-sha-hmac no compression

         in use settings ={L2L, Tunnel, }

         slot: 0, conn_id: 50290688, crypto-map: SYSTEM_DEFAULT_CRYPTO_MAP

         sa timing: remaining key lifetime (sec): 19446

         IV size: 8 bytes

         replay detection support: Y

         Anti replay bitmap:

          0x00000000 0x00000001

[Julio Carvajal]

Hello Manjitriat,

Seems like the configuration is the one required, as you can see the status of the vpn tunnel is active.

I would definetly recommend you to check the configuration on both sides regarding the encryption, authentication,etc, this to  confirm both devices has the same settings because as I can tell you the configuration on this one is fine,

Regards,

Julio

[manjitriat]

Julio,

Thank you for the reply. I am completely at a loss here too but have found something interesting. On the Sonicwall I saw the counters show a bunch of packets sent and nothing recieved so I logged into ASDM and viewed the VPN tunnel properties and it shows the same a bunch of packets but 0 sent. So looks like the ASA is recieving traffic from the Sonicwall over the tunnel but not routing any traffic over the VPN tunnel back to the Sonicwall and possibly sending it somewhere else.

[Julio Carvajal]

Hello Manji,

If you do a show run route, do you see one that matches the destination (could be a default route 0.0.0.0 0.0.0.0)

Are you able to see that?

Also can you send me the output of :

show run access-group

show run access-list

Regards,

Julio

[manjitriat]

On the show run route I don't see a route to the remote network and so yes it might be just on the default

route outside 0.0.0.0 0.0.0.0 x.x.x.x 1

#show run access-group is blank

#show run access-list

access-list outside_access_in extended permit ip 10.20.10.0 255.255.255.0 10.20.2.0 255.255.255.0

access-list nonat extended permit ip 10.20.2.0 255.255.255.0 10.20.12.0 255.255.255.0

access-list nonat extended permit ip 10.20.4.0 255.255.255.0 10.20.12.0 255.255.255.0

access-list nonat extended permit ip 10.20.2.0 255.255.255.0 10.20.10.0 255.255.255.0

access-list outside_2_cryptomap extended permit ip 10.20.2.0 255.255.255.0 10.20.10.0 255.255.255.0

[Julio Carvajal]

Hello Manjitriat,

1-Do you have the ICMP inspect enable over your policy_global?? If not please add it

2-Can you try to ping from one internal host to another host behind the sonic firewall, Afterwards take a show crypto isakamp sa and ipsec sa

Regards,

Julio

[manjitriat]

Yes inspect icmp is enabled in global_policy

The ping requests time out (The only ping that works is when I ping from the remote side to the ASA internal IP address, no other pings from either side work)

#show crypto isakmp sa

1   IKE Peer: x.x.x.x

    Type    : L2L             Role    : responder

    Rekey   : no              State   : MM_ACTIVE

#show crypto ipsec sa

interface: outside

    Crypto map tag: outside_map, seq num: 1, local addr: x.x.x.x

      access-list outside_2_cryptomap extended permit ip 10.20.2.0 255.255.255.0 10.20.10.0 255.255.255.0

      local ident (addr/mask/prot/port): (10.20.2.0/255.255.255.0/0/0)

      remote ident (addr/mask/prot/port): (10.20.10.0/255.255.255.0/0/0)

      current_peer: y.y.y.y

      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

      #pkts decaps: 39543, #pkts decrypt: 39543, #pkts verify: 39543

      #pkts compressed: 0, #pkts decompressed: 0

      #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0

      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

      #send errors: 0, #recv errors: 0

      local crypto endpt.: x.x.x.x, remote crypto endpt.: y.y.y.y

      path mtu 1500, ipsec overhead 58, media mtu 1500

      current outbound spi: 0ED0F897

      current inbound spi : 596CCE6F

    inbound esp sas:

      spi: 0x596CCE6F (1500302959)

         transform: esp-3des esp-sha-hmac no compression

         in use settings ={L2L, Tunnel, PFS Group 2, }

         slot: 0, conn_id: 50327552, crypto-map: outside_map

         sa timing: remaining key lifetime (sec): 7440

         IV size: 8 bytes

         replay detection support: Y

         Anti replay bitmap:

          0xFFFFFFFF 0xFFFFFFFF

    outbound esp sas:

      spi: 0x0ED0F897 (248576151)

         transform: esp-3des esp-sha-hmac no compression

         in use settings ={L2L, Tunnel, PFS Group 2, }

         slot: 0, conn_id: 50327552, crypto-map: outside_map

         sa timing: remaining key lifetime (sec): 7440

         IV size: 8 bytes

         replay detection support: Y

         Anti replay bitmap:

          0x00000000 0x00000001

[manjitriat]

Julio,

This issue has been resolved. Didn't realize there was a static route added on a Layer 3 switch behind the ASA. Deleted that route and everything seems to be working fine.

Thank you for you help

[Julio Carvajal]

Hello Manjitriat,

Good to know, so as we suspected everything was perfect on the ASA.

Hope you have a great day.

Julio