isakmp per info not found, some solutions

Discussion in 'Cisco' started by Walter Roberson, Mar 2, 2005.

  1. If one turns on debug isakmp under IOS or PIX, one may see
    a message saying (approximately)

    VPN :ISAKMP: peer info for not found

    Searching Cisco's web site via google (or Cisco's search
    tool which uses google's technology) will not find
    any hits for this. A few dozen postings over the years have
    asked about this, but there has rarely been a useful
    solution posted.

    If one looks in Cisco's document on troubleshooting VPN's,
    there is information on this message. Unfortunately
    that information is hard to read, and talks about matters
    such as "intersecting traffic" without explanation. If one
    reads the description there a number of times and looks at
    the accompanying example, it -appears- that the description is
    saying the problem occurs if the IPSec transforms do not match
    up properly... on the other hand, the description could just
    as easily be saying that the problem occurs if the exchanged
    ACLs do not match... a difficulty that would tend to lead
    to a different message. One gets the impression that the
    description was translated from another language.

    The Cisco description of the message seems to indicate that
    the message would be generated just as the layer 2 ipsec
    attributes were being exchanged. This is not always helpful:
    PIX debug sessions may show progress much further than that,
    including showing sending an ACL from one end just after
    "floating port detected" in NAT-T processing.

    After tracking down some cases of this today, I offer the
    following debug steps:

    1) If you are using pre-shared keys, ensure that your keys are the same
    on both ends. If this is your problem then one of the ends may show the
    debug message "reserved is not zero at payload" followed by a number.
    Meanwhile, the other end may show the "per info not found" message

    2) Check that the ipsec transforms are the same at both ends,
    or at least that the first of them is same. IPsec -should- be
    able to negotiate transforms in this case, but on the PIX at
    least, that negotiation does not always work. (It is possible
    that the negotation failure is related to NAT-T being on -- that is,
    potentially the two ends would settle on a mutally agreeable
    transform if you did not have NAT-T on.)

    3) Ensure that each device knows the route to the other. If
    the crypto interface on the device is attached to a LAN/WAN that
    has a route back, then layer 1 ipsec negotiation will succeed,
    as will partial NAT-T negotiations. However, in order to finish
    NAT-T negotations, the crypto device itself needs to know the route:
    after a point it stops just punting the packets out the interface
    and starts trying to route the packets. If the device route to the
    remote endpoint does not pass through the crypto interface, then
    the side with the routing problem will not submit the proxy ACL to
    the other end, but the side that does not have a routing problem
    will think it has finished NAT-T negotiations and will submit
    a proxy ACL. The side that has the routing problem is the one
    more likely to give the peer info not found message, but the other
    end may eventually give the message as well.

    4) Ensure that no intermediate system is blocking the packets;
    in particular if you have NAT-T turned on, ensure that UDP 4500 is
    available end to end. If there is a block, then the effect is the
    same as if there is a routing problem.

    I hit #4 in the late hours of last night, and I hit the
    other three this afternoon/evening. In -most- cases the default
    route will take care of #3, but in my most troublesome case
    today the default route pointed out the outside interface and
    it happened that the inside interface was my VPN endpoint.
    We don't need no side effect-ing
    We don't need no scope control
    No global variables for execution
    Hey! Did you leave those args alone? -- decvax!utzoo!utcsrgv!roderick
    Walter Roberson, Mar 2, 2005
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jens Mander

    Per-to-Per is OK but no ICS

    Jens Mander, Jan 15, 2005, in forum: Wireless Networking
    Carey Holzman
    Jan 23, 2005
  2. jt
  3. R Siffredi

    Per packet vs per flow routing

    R Siffredi, Mar 22, 2005, in forum: Cisco
    Hansang Bae
    Mar 24, 2005
  4. lfnetworking
    Sep 27, 2006

Share This Page