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?