cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
500
Views
0
Helpful
2
Replies

Crypto Maps and VPN traffic flow

J W
Level 1
Level 1

Hello! I think I have what is an easy question for people here. We had some issues setting up a IPSec VPN between an ASA 5510 and a Sonicwall (Shame!) on a network that was inherited.

Essentially we have a couple of DHCP servers that were not able to communicate with any device on the other end of the tunnel, including the interface of the remote Sonicwall (192.168.7.1). Any other node on the ASA side of the tunnel could hit anything on the Sonicwall (including the interface 192.168.7.1).

This is the ACL associated with the Cryptomap for this tunnel:

access-list outside_6_cryptomap extended permit ip object-group DHCP_Servers host <WAN_IP_OF_SONICWALL_PEER)
access-list outside_6_cryptomap extended permit ip object-group DHCP_Servers host 192.168.7.1
access-list outside_6_cryptomap extended permit ip object-group DM_INLINE_NETWORK_17 192.168.7.0 255.255.255.0

The group "DM_INLINE_NETWORK_17" in the above ACL is a group containing the internal subnets that are behind the ASA, which includes 

network-object 172.16.0.0 255.255.0.0

What we ended up having to do to get this to work was to inactivate the second line in the ACL: access-list outside_6_cryptomap extended permit ip object-group DHCP_Servers host 192.168.7.1

My question is why this fixed this particular issue. I am just trying to gain a better understanding of whats taking place here. I think it's odd that they are advertising 172.16.0.0/16 on one end, and 172.16.7.0/24 on the other, but things seem to be working with the aforementioned ACE being disabled. 

Can anyone shed any light on this?

Thank you!

1 Accepted Solution

Accepted Solutions

JP Miranda Z
Cisco Employee
Cisco Employee

Hi jarednwesley,

Essentially this fails because of the traffic ovelapping between the Security Associations:

-if you have a network 172.16.0.0/16 going to 192.168.7.0/24 why would you configure a now ACE from host to host that are already part of the networks we already have allowed through the tunnel.

-This type of misconfiguration can cause from traffic issues since some traffic could be trying to go through the SA from 172.16.0.0/16 to 192.168.7.0/24 and other traffic trying to go through  172.16.7.0/24 to the host 192.168.7.1 and this is definitely going to cause unexpected behaviors on the tunnel.

That explains why as soon as you removed the new ACE the tunnel works fine, since the tunnel is finding a completely redundant ACE and is interfering with the flow of the traffic through the tunnel.

Hope this info helps!!

Rate if helps you!! 

-JP- 

View solution in original post

2 Replies 2

JP Miranda Z
Cisco Employee
Cisco Employee

Hi jarednwesley,

Essentially this fails because of the traffic ovelapping between the Security Associations:

-if you have a network 172.16.0.0/16 going to 192.168.7.0/24 why would you configure a now ACE from host to host that are already part of the networks we already have allowed through the tunnel.

-This type of misconfiguration can cause from traffic issues since some traffic could be trying to go through the SA from 172.16.0.0/16 to 192.168.7.0/24 and other traffic trying to go through  172.16.7.0/24 to the host 192.168.7.1 and this is definitely going to cause unexpected behaviors on the tunnel.

That explains why as soon as you removed the new ACE the tunnel works fine, since the tunnel is finding a completely redundant ACE and is interfering with the flow of the traffic through the tunnel.

Hope this info helps!!

Rate if helps you!! 

-JP- 

J W
Level 1
Level 1

Thank you, JP!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: