cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1554
Views
0
Helpful
17
Replies

Site to Site tunnel, getting an error

shall
Level 1
Level 1

I am setting up a site to site VPN with a 881 and a PIX box.  On the 881 I am getting an error when I test the VPN through CCP.  

 

"The peer must be routed through the crypto map interface.  The Following peer(s) do not a have a routing entry in the routing table

1) 66.66.66.66

 

Where do I add the route?  In IPSec-->IPSec Policies (Crypto Map Sets) I see the correct peer in there.  What am I missing?

1 Accepted Solution

Accepted Solutions

When you ping from the CLI are you using extended ping and specifying the source interface ?

To be honest I wouldn't worry if the clients can communicate.

With things like NAT and VPNs I always try to test from end devices because this means traffic is passing through the router from one interface to another.

Testing from the router or firewall itself can lead to inconsistent results.

Jon

View solution in original post

17 Replies 17

Richard Burts
Hall of Fame
Hall of Fame

What you are missing appears to be in the IP routing section and not in the crypto section.

 

HTH

 

Rick

HTH

Rick

I have the static route and have internet.  That is the only route I have created before.  Is that where I need to add it?

We do not know enough about your environment to know what to advise you. If you have a static route and have internet that is good and might be enough. Can you ping the address of the peer? If so then the warning might be an artifact of CCP.  Perhaps more important than what CCP says is the question of whether the VPN comes up when you try to run real traffic through it.

 

HTH

 

Rick

HTH

Rick

I can ping the peer but no traffic can be sent.  Here is my config if that will help.

 

66.66.66.66 is my peer IP address external and 192.168.1.0/24 is my internal
77.77.77.77 is my ip address and 192.168.2.0/24 is my internal



Here is my config


#sho running
Building configuration...

Current configuration : 3222 bytes
!
! Last configuration change at 18:13:30 UTC Mon Mar 9 2015 by admin
version 15.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
aqm-register-fnf
!
enable secret 5 $1$btOW$jmymDGZBSU72TLsGPCycN.
enable password XXXXXXX
!
no aaa new-model
!
!
!
!
!
!


!
ip dhcp excluded-address 192.168.2.1 192.168.2.50
ip dhcp excluded-address 192.168.2.201 192.168.2.254
!
ip dhcp pool Router
import all
network 192.168.2.0 255.255.255.0
dns-server 69.71.1.3 69.71.0.3
!
!
!
ip name-server 69.71.1.3
ip name-server 69.71.0.3
ip cef
no ipv6 cef
!
!
!
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
license udi pid C881-K9 sn FTX184783XN
!
!
username admin privilege 15 password 0 XXXXXXX
!
!
!
!
!
!
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
!
crypto isakmp policy 2
hash md5
authentication pre-share
group 2
crypto isakmp key XXXXXXXX address 66.66.66.66
!
!
crypto ipsec transform-set VPN esp-3des esp-sha-hmac
mode tunnel
!
!
!
crypto map SDM_CMAP_1 1 ipsec-isakmp
description Tunnel to66.66.66.66
set peer 66.66.66.66
set transform-set VPN
match address 104
!
!
!
!
!
!
interface FastEthernet0
no ip address
!
interface FastEthernet1
no ip address
!
interface FastEthernet2
no ip address
!
interface FastEthernet3
no ip address
!
interface FastEthernet4
description $ETH-LAN$
ip address 77.77.77.77 255.255.255.248
ip nat outside
ip virtual-reassembly in
duplex half
speed auto
crypto map SDM_CMAP_1
!
interface Vlan1
ip address 192.168.2.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
!
ip forward-protocol nd
ip http server
ip http authentication local
no ip http secure-server
!
!
ip nat inside source route-map SDM_RMAP_1 interface FastEthernet4 overload
ip route 0.0.0.0 0.0.0.0 FastEthernet4 77.77.77.76
!
ip sla auto discovery
dialer-list 1 protocol ip permit
!
route-map SDM_RMAP_1 permit 1
match ip address 101
!
access-list 1 remark CCP_ACL Category=2
access-list 1 permit 192.168.2.0 0.0.0.255
access-list 100 remark CCP_ACL Category=4
access-list 100 remark IPSec Rule
access-list 100 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 101 remark CCP_ACL Category=2
access-list 101 remark IPSec Rule
access-list 101 deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 101 permit ip 192.168.2.0 0.0.0.255 any
access-list 102 remark CCP_ACL Category=4
access-list 102 remark IPSec Rule
access-list 102 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 103 remark CCP_ACL Category=4
access-list 103 remark IPSec Rule
access-list 103 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 104 remark CCP_ACL Category=4
access-list 104 remark IPSec Rule
access-list 104 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
!
control-plane
!
!
!
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none
mgcp behavior comedia-check-media-src disable
mgcp behavior comedia-sdp-force disable
!
mgcp profile default
!
!
!
!
!
line con 0
no modem enable
line aux 0
line vty 0 4
password XXXXXXXX
login local
transport input all
!
scheduler allocate 20000 1000
!
end

Your config looks okay to me so I don't know what CCP is complaining about.

I would modify the default route and just have the next hop IP although I doubt this is the issue.

From the CLI -

"debug crypto isakmp"
"debug crypto ipsec"

then try to initiate a connection from a 192.168.2.x client ie. not from the router itself.

Jon

Thanks for the reply Jon.  I did the following

 

From the CLI -

"debug crypto isakmp"
"debug crypto ipsec"

tried to ping from 192.168.2.x to 192.168.1.x from the clients PC and it timed out.  The VPN is still down.  Tried to ping from the 881 CLI with no luck.  Success rate is 0 percent (0/5)

Can you try from the other end and leave the debugging on ?

Jon

Same result from the other side.  With debugging on.  Where can I see debug info?

If you are logged on to the router you should see it on the screen.

I can't see anything obviously wrong with your configuration and even if the tunnel didn't come up you should at least see some activity.

I'll have a dig around to see if there is anything special you need to do for an 881 router although I doubt it.

Can you from the CLI remove the crypto map from the interface and then reapply it just in case the router has got a bit confused.

Jon

I'll try to remove it from the command line.  I don't see anything when I am logged in the router so something is confused.

I ended up getting the tunnel up.  I removed everything from CCP VPN configuration and re-created it in CLI.  

 

I do have 1 issue (I think)  From the work stations at 192.168.2.0/24 network I can ping 192.168.1.X/24 and vise versa.  But from the 881 CLI I can only ping 192.168.1.2 across the vpn. The rest of the 192.168.1.X times out.  Is that just something on the 881 that is weird and I shouldn't worry about?  Doesn't make sense to me why I can from the work stations.

When you ping from the CLI are you using extended ping and specifying the source interface ?

To be honest I wouldn't worry if the clients can communicate.

With things like NAT and VPNs I always try to test from end devices because this means traffic is passing through the router from one interface to another.

Testing from the router or firewall itself can lead to inconsistent results.

Jon

Thanks for posting the additional information. Based on what I see in the config I am convinced that the message you mention in the original post is just something generated by CCP. Your router does have a route to reach 66.66.66.66 and it is reached via the interface where the crypto map is applied. So I would consider this a flaw in CCP.

 

Looking at the configuration it seems reasonable. You say that you can ping the peer and that is a good sign. Do you have access to the peer device? Could you post the configuration of the peer?

 

Perhaps if you enable debug on your router it might show us something about the issue. I would start with debug crypto isakmp.

 

A very common source of problems is that the peer statements do not match or that the preshared key does not match. It might be worth the effort to remove the configured key on both peers and configure it over again.

 

HTH

 

Rick

HTH

Rick

There are a couple of things I would like to comment about.

 

In an earlier post Jon suggests changing the configured default route removing the reference to the outbound interface. While I do not object to trying that as an experiment I would be extremely surprised if that were an issue. It is a quite valid configuration of a static route to specify both the outbound interface and the next hop. I do that in some circumstances and have never seen it cause a problem.

 

As for how to see the debug output we do not know the status of logging on this router. There are no logging commands shown in the config and I do not know what the default settings are on this device. If the original poster can post the first page or so of output from the command show logging we would have a much better understanding of the logging environment. And then would be in a better position to discuss how to see the debug output.

 

HTH

 

Rick

 

[edit] And the fact that the original poster says that he can ping the peer address is one point that indicates that the default route is working ok.

 

HTH

Rick