[c-nsp] crypto map working on outbound interface, need it to work on inbound interface
Joseph Mays
mays at win.net
Tue Dec 13 17:49:04 EST 2011
Mostly I was just trying to find out, never having used the local address parameter in the global crypto map config, if I was using it correctly. Here is the debug output you mentioned.
With the config shown below, pinging from 24.235.0.25 to 65.119.118.76 to bring the vpn up...
Router#show debug
Generic IP:
ICMP packet debugging is on
Cryptographic Subsystem:
Crypto ISAKMP Error debugging is on
Crypto ISAKMP High Availability debugging is on
Crypto IPSEC Error debugging is on
Crypto High Availability Manager debugging is on
Crypto IPSEC High Availability debugging is on
Router#
*Apr 5 07:17:28.703: ISAKMP:(0:0:N/A:0):Notify has no hash. Rejected.
*Apr 5 07:17:28.707: ISAKMP (0:0): Unknown Input IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY: state = IKE_I_MM1
*Apr 5 07:17:28.707: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Informational mode failed with peer at 65.119.118.136
*Apr 5 07:17:58.667: ISAKMP:(0:0:N/A:0):SA is still budding. Attached new ipsec request to it. (local 24.235.0.26, remote 65.119.118.136)
*Apr 5 07:18:01.359: %SEC-6-IPACCESSLOGDP: list PHL-3845-SS7-VPN permitted icmp 24.235.0.25 -> 65.119.118.76 (8/0), 282 packets
*Apr 5 07:18:29.071: ISAKMP:(0:0:N/A:0):Notify has no hash. Rejected.
*Apr 5 07:18:29.071: ISAKMP (0:0): Unknown Input IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY: state = IKE_I_MM1
*Apr 5 07:18:29.071: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Informational mode failed with peer at 65.119.118.136
*Apr 5 07:18:59.031: ISAKMP:(0:0:N/A:0):SA is still budding. Attached new ipsec request to it. (local 24.235.0.26, remote 65.119.118.136)
*Apr 5 07:19:29.291: ISAKMP:(0:0:N/A:0):Notify has no hash. Rejected.
*Apr 5 07:19:29.291: ISAKMP (0:0): Unknown Input IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY: state = IKE_I_MM1
*Apr 5 07:19:29.291: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Informational mode failed with peer at 65.119.118.136
*Apr 5 07:19:36.247: ICMP: time exceeded (time to live) sent to 118.96.20.16 (dest was 216.135.93.64)
*Apr 5 07:19:42.315: ICMP: time exceeded (time to live) sent to 212.67.88.93 (dest was 24.235.0.25)
*Apr 5 07:19:59.251: ISAKMP:(0:0:N/A:0):SA is still budding. Attached new ipsec request to it. (local 24.235.0.26, remote 65.119.118.136)
*Apr 5 07:20:29.315: ISAKMP:(0:0:N/A:0):Notify has no hash. Rejected.
*Apr 5 07:20:29.319: ISAKMP (0:0): Unknown Input IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY: state = IKE_I_MM1
*Apr 5 07:20:29.319: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Informational mode failed with peer at 65.119.118.136
*Apr 5 07:20:49.895: ICMP: time exceeded (time to live) sent to 121.14.69.250 (dest was 216.135.93.72)
*Apr 5 07:20:59.279: ISAKMP:(0:0:N/A:0):SA is still budding. Attached new ipsec request to it. (local 24.235.0.26, remote 65.119.118.136)
*Apr 5 07:21:29.555: ISAKMP:(0:0:N/A:0):Notify has no hash. Rejected.
*Apr 5 07:21:29.555: ISAKMP (0:0): Unknown Input IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY: state = IKE_I_MM1
*Apr 5 07:21:29.559: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Informational mode failed with peer at 65.119.118.136
----- Original Message -----
From: Clint Wade
To: Joseph Mays
Cc: cisco-nsp at puck.nether.net
Sent: Tuesday, December 13, 2011 5:29 PM
Subject: Re: [c-nsp] crypto map working on outbound interface, need it to work on inbound interface
Joseph,
With anything VPN related it may be better to either post outputs of a 'debug isakmp sa' or 'debug ipsec sa' or the relevent portions of the configurations on both devices. It's not easy to get an idea of what is going on with small config snippets.
Regards,
Clint Wade
On Tue, Dec 13, 2011 at 4:22 PM, Joseph Mays <mays at win.net> wrote:
So, in the example below, will this cause the vpn to connect to the peer from FastEthernet0/0, but identify as the ip address of FastEthernet1/1?
crypto map WinnetToSyniverse local-address FastEthernet1/1
crypto map WinnetToSyniverse 20 ipsec-isakmp
description PHL-3845-SS7-VPN router
set peer 65.119.118.136
set transform-set TSI2
match address PHL-3845-SS7-VPN
!
!
!
interface FastEthernet0/0
ip address 216.135.80.50 255.255.255.252
duplex auto
speed auto
crypto map WinnetToSyniverse
----- Original Message ----- From: "Joseph Mays" <mays at win.net>
To: <cisco-nsp at puck.nether.net>
Sent: Tuesday, December 13, 2011 3:41 PM
Subject: [c-nsp] crypto map working on outbound interface,need it to work on inbound interface
Have a crypto map that was working to build a tunnel between 65.119.118.75 and 24.235.0.25. Peers for the vpn tunnel were 24.235.0.26 and 65.119.118.136. Due to some network changes 24.235.0.26, which was the egress interface toward the remote end, is now an ingress interface. Still, I don't see why this should matter. The access list is the same, it's just traffic coming in through the interface rather than out of it.
Crypto Map "WinnetToSyniverse" 20 ipsec-isakmp
Description: PHL-3845-SS7-VPN router
Peer = 65.119.118.136
Extended IP access list PHL-3845-SS7-VPN
access-list PHL-3845-SS7-VPN permit ip host 24.235.0.25 host 65.119.118.76
Current peer: 65.119.118.136
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={
TSI2,
}
Interfaces using crypto map WinnetToSyniverse:
FastEthernet1/1
The packets for the access list should match regardless of direction, but it acts like it's not matching packets to the access list and not even trying to start the vpn.
Router#show crypto isakmp sa
dst src state conn-id slot status
Nothing there.
I can ping 65.119.118.136 from the router even when I set the source address to the address of the ingress interface, 24.235.0.26, and can ping the host we are trying to talk to across the vpn, 65.119.118.76, from 24.235.0.25.
I moved the crypto map command to the outside interface and it started matching packets tried to bring the vpn tunnel up, but that failed, I'm guessing because the source address changed to the address of the egress interface, which would not be the address configured in the remote side. So I want to use the ingress interface and its address so we don't have to go through a complex process to get the other side to reconfigure.
_______________________________________________
cisco-nsp mailing list cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list