Re: peer matches *none* of the profiles??

pculmsee · ‎02-06-2005

Hi

Any ideas here?

I am writing up a document on getting a Linksys WAG54G to do an IPSEC Tunnel with an IOS router. I have it all working fine, but I thought I would

annotate the Cisco logs here and there to make it easier for the reader.

Just at the end of IKE Phase 1, when the peers verify eachothers identify (in my example, by IP address), I see this and I'm not sure whats going on.. (IP's have been changed)

Feb 6 21:43:06.942 GMT: ISAKMP (0:709): Old State = IKE_R_MM4 New State = IKE_R_MM5

Feb 6 21:43:06.942 GMT: ISAKMP (0:709): processing ID payload. message ID = 0

Feb 6 21:43:06.942 GMT: ISAKMP (0:709): ID payload

next-payload : 8

type : 1

address : 200.100.1.1

protocol : 0

port : 0

length : 12

Ok so the peer has sent its identity info as per the 3rd main mode exchange of IKE Phase 1. Then what the heck does this signify?

Feb 6 21:43:06.942 GMT: ISAKMP (0:709): peer matches *none* of the profiles

Okay next it looks like it is checking the hash of the above..

Feb 6 21:43:06.942 GMT: ISAKMP (0:709): processing HASH payload. message ID = 0

Feb 6 21:43:06.946 GMT: ISAKMP (0:709): SA authentication status:

Feb 6 21:43:06.946 GMT: authenticated

Feb 6 21:43:06.946 GMT: ISAKMP (0:709): SA has been authenticated with 200.100.1.1

Great, the hash checks out and we are happy?? But here it is again!

Feb 6 21:43:06.946 GMT: ISAKMP (0:709): peer matches *none* of the profiles

Then it sends my ID payload to the Linksys peer..

Feb 6 21:43:06.946 GMT: ISAKMP (0:709): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

Feb 6 21:43:06.946 GMT: ISAKMP (0:709): Old State = IKE_R_MM5 New State = IKE_R_MM5

Feb 6 21:43:06.946 GMT: ISAKMP (0:709): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR

Feb 6 21:43:06.946 GMT: ISAKMP (0:709): ID payload

next-payload : 8

type : 1

address : 200.56.4.1

protocol : 17

port : 500

length : 12

Feb 6 21:43:06.946 GMT: ISAKMP (709): Total payload length: 12

Feb 6 21:43:06.946 GMT: ISAKMP (0:709): sending packet to 200.100.1.1 my_port 500 peer_port 500 (R) MM_KEY_EXCH

Looks like it worked ok, because Phase 1 completes..

Feb 6 21:43:06.946 GMT: ISAKMP (0:709): Input =

IKE_MESG_INTERNAL,IKE_PROCESS_COMPLETE

Feb 6 21:43:06.946 GMT: ISAKMP (0:709): Old State = IKE_R_MM5 New State = IKE_P1_COMPLETE

Feb 6 21:43:06.946 GMT: ISAKMP (0:709): Input =

IKE_MESG_INTERNAL,IKE_PHASE1_COMPLETE

Feb 6 21:43:06.946 GMT: ISAKMP (0:709): Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE

So I really do not understand what is meant by this message peer matches *none* of the profiles??

thanks

Paul

gfullage · ‎02-06-2005

IPSec profiles came in in 12.2(15)T as part of per-VRF IPSec (http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/ft_vrfip.htm). This was a different way to configure IPsec peers giving you much more granularity in matching peers, although you can still use the old way which I'm presuming you're doing.

A side-effect of running a version that supports IPSec profiles is that IOS will check to see if your peer address has a matching profile whenever it negotiates. Because (again I'm assuming) you haven't configured any, you get a debug message saying that your peer address doesn't match any.

It's nothing to worry about and can be safely ignored, takes about 1 nanosecond to do the check during the tunnel build so it's not causing any undue delays or anything.

Hope that helps.

pculmsee · ‎02-06-2005

Yes it does indeed. I am not running VRF as its a single company setup.

Thanks for clearing that up..

Paul