Cisco_Sonicwall - VPN policy's Destination Network (Phase 2) Mismatch 1

[th3machine]

Hello everybody,

I need your help with a VPN that's driving me crazy.

I have to establish a tunnel between a Cisco C837 and a SonicWALL PRO 4100.

- The Cisco router has a dynamic public IP.
- Cisco local network: 172.16.41.24/29

- The SW has a static public IP.
- SW local network: 172.16.40.0/26

Aggressive Mode Phase 1 completes OK, but in Phase 2 SonicWALL log says:
"IKE Responder: Peer's local network does not match VPN policy's Destination Network"
"VPN Policy: pruebasdhcp; Proposed network: 0.0.0.0/0.0.0.0"

As the SW works fine with many other VPNs (to other routers with dynamic or static public IPs) I think the problem is located in the Cisco ACLs (I've also been able to establish a VPN between these two devices... but in Main Mode with static IPs), because trying to establish connection is up to one or two code lines --though it fails at Phase 2--.

I'll put some code to explain the situation:

--

crypto isakmp policy 20
encr 3des
authentication pre-share
group 2
lifetime 28800

crypto isakmp peer address XXX.XXX.XXX.XXX
set aggressive-mode password XXX
set aggressive-mode client-endpoint user-fqdn XXX@XXX.XX
!
crypto ipsec security-association lifetime seconds 28800
!
crypto ipsec transform-set sonicwall esp-3des esp-sha-hmac
!
crypto map sonicwallmap 20 ipsec-isakmp
description Tunel
set peer XXX.XXX.XXX.XXX
set transform-set sonicwall
match address 120

interface Ethernet0
ip address 172.16.41.25 255.255.255.248
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1452
no ip mroute-cache
hold-queue 100 out

interface ATM0
no ip address
ip nat outside
ip virtual-reassembly
no atm ilmi-keepalive
dsl operating-mode auto
pvc 8/32
pppoe-client dial-pool-number 1
!
interface Dialer1
ip address negotiated
ip access-group ext_fw in
ip mtu 1404
ip nat outside
ip virtual-reassembly
encapsulation ppp
ip tcp adjust-mss 1452
dialer pool 1
dialer-group 1
ppp authentication pap callin
ppp chap hostname XXX
ppp chap password 7 XXX
ppp pap sent-username XXX
ppp ipcp dns request
ppp ipcp wins request
crypto map sonicwallmap
hold-queue 224 in

ip route 0.0.0.0 0.0.0.0 Dialer1

ip nat inside source list 120 interface Dialer1 overload
ip nat inside source route-map nonat interface Dialer1 overload

ip access-list extended ext_fw
deny icmp any any redirect
permit tcp any any established
permit udp any any gt 1023
permit udp any any eq isakmp
permit icmp any any
permit ahp any any
permit esp any any

access-list 100 deny ip 172.16.41.24 0.0.0.7 172.16.40.0 0.0.0.63
access-list 100 permit ip 172.16.41.24 0.0.0.7 any
access-list 120 permit ip 172.16.41.24 0.0.0.7 172.16.40.0 0.0.0.63

route-map nonat permit 10
match ip address 100

--

With the configuration shown above, SW doesn't know there's a router trying to establish a VPN connection.

It only starts negotiating if I add the line:
access-list 120 permit icmp any any

But it has the following consequences:
- Ping isn't allowed anymore from Cisco router.
- "show crypto ipsec sa" shows first tunnel as:

interface: Dialer1
Crypto map tag: sonicwallmap, local addr XXX.XXX.XXX.XXX

protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/1/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/1/0)
current_peer XXX.XXX.XXX.XXX port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

But, if I remove that line (access-list 120 permit icmp any any), I can see:
protected vrf: (none)
local ident (addr/mask/prot/port): (172.16.41.24/255.255.255.248/0/0)
remote ident (addr/mask/prot/port): (172.16.40.0/255.255.255.192/0/0)
But nothing happens (neither phase 1 tries to start).

Any help would be appreciated.

 

[brianinms]

You have the sonicwall misconfigured, it thinks the crypto acl is 0.0.0.0 0.0.0.0. It needs to be a mirror image of ACL 120.

 

[th3machine]

I got it!!!

Thanks for your advice, brianinms. Obviously ACL 120 didn't match, so I removed the conflictive line:
access-list 120 permit icmp any any

I removed some unnecesary lines too and finally got it working in aggressive mode... because basically it was well configured.

The problem was located in the way of making negotiation start. I was pinging from the router and today I realized that traffic had to come from the very end, that is, the computer.

And it works.