03-31-2009 11:50 AM - edited 02-21-2020 03:23 AM
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.
04-28-2009 11:41 AM
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...
04-28-2009 01:41 PM
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.
04-28-2009 02:31 PM
Thanks much for your reply. I will try this out and will repost the results...
04-29-2009 01:55 PM
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...
04-29-2009 02:01 PM
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
04-29-2009 02:11 PM
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...
04-29-2009 02:14 PM
It is a dynamic ip address hence the SW should have a wildcard preshared key
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide