cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10124
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

The SW guy said that to run in Main Mode, he had to build the Tunnels with a Peer IP Address and we won't have a "static" ip at the 871 end...

Kporter,

I understand your frustration. I ran into the same issue that you are having a few months ago and I was able to get my remote workers to connect between 871w and SonicWall 2040.

Forget about creating VPN policies on your SonicWall, it will not work with any of the modes since your remote 871 is using dynamic WAN IP. Try below.

SonicWall Settings.

Use the default GroupVPN policies and set to use IKE preshare secret.

Phase1- Group2, 3DES, SHA1, 28800.

Phase2- ESP, 3DES, SHA1

Turn off PFS

Unchecked all advanced settings

Enable your GroupVPN policy

871 Settings.

crypto isakmp policy 10

encr 3des

authentication pre-share

group 2

crypto isakmp key Interior2009 address 63.252.122.130 no-xauth

let me know how it goes. Good luck.

Thanks much for your reply. I will try this out and will repost the results...

No joy! I cannot confirm 100% that the SW is configured as you suggested since I am not allowed to touch it. Looks like Phase 1 is not completing now, since the router is doing a lot of "retransmitting phase 1 MM_KEY_EXCHANGE" messages...

Key exchange means the preshare key or the identity is wrong, can you check if you can enable this on the router Crypto isakmp identity address

The ID Payload was sending the Address of the WAN port that is using DHCP. Does the SW need to know the Identity of the 871 Router? If so, I would think that using the Hostname would be preferred, since that would never change...

It is a dynamic ip address hence the SW should have a wildcard preshared key

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:

Recognize Your Peers