cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10137
Views
5
Helpful
21
Replies

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

themachine
Beginner
Beginner

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.

21 Replies 21

Ivan Martinon
Rising star
Rising star

Hi, I wonder why do you force the router to start the vpn tunnel as aggressive mode. The router indeed has a dynamic ip address, but as far as the SW supports the establishment of tunnels with a dynamic ip addres you should not use aggressive mode. As well i would like to know why do you have the following NAT line:

ip nat inside source list 120 interface Dialer1 overload

This line is using the same acl that match address on the crypto statements so pretty much you are overloading the whole network to the dialer when going to the tunnel.. I would get rid of it.

I got it!!!

Thanks for your advices, imartino. I removed some unnecesary lines and finally got it working in aggressive mode... obviously without the conflictive line:

access-list 120 permit icmp any any

that was making mismatch both ends.

So, 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.

Hi. I am trying to get a Cisco 871 to VPN connect to a Sonicwall and we are failing Phase 1. The router is using DHCP on the WAN. The Sonicwall is static. The router will not start Agressive Mode, which appears to be a problem at the Sonicwall. Any thoughts on what to check on the Sonicwall and the router would be greatly appreciated...

Yes, does your router have configuration to connect to a static vpn or does it have configuration of an aggressive mode setup?

I am connecting to the Sonicwall's Static IP. The router is set for DHCP. Since I don't have a static IP for the Router, I'm assuming that I cannot use Aggressive Mode, since the "crypto isakmp peer X.X.X.X" command is looking for my Routers static IP...