1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.


Discussion in 'Cisco Small Business Routers and VPN Solutions' started by schwa13, May 12, 2004.

  1. schwa13

    schwa13 Network Guru Member

    Have spent most of the day trying to get these two devices to talk to each other. The 3COM is up and running and can communicate with other IPSEC VPN devices without issue.

    The linksys log reports either:

    "ignoring information payload, type INVALID_EXCHANGE_TYPE"


    "ignoring information payload, type INVALID_ID_INFORMATION"

    I have played with DES, 3DES, shared keys, key lifetimes, perfect forward secrecy, MD5, SHA, and just about every other setting on this thing. I just can't find right setting to get both sides to link up.

    Anyone have any ideas as to what those error messages mean? I can't find much online except the RFC for FreeSwan. Not very descriptive...

  2. Nige

    Nige Network Guru Member

    I've had INVALID_ID_INFORMATION before, I believe it refers to the remote host (other end of the tunnel) identification string, which can be a fully qualified domain name, an IP address, or a network.

    The easiest way to approach this is to make sure that neither of your devices are NAT'ed, that the IP address that the other device uses to identify it is public, and that you identify them by their IP address in the configuration. That avoids any DNS problems on either end. Also, for the network you're providing access to, use numeric ip address/mask rather than a domain (same DNS reason).

    Avoid using 'any' for identifying the remote device, that will screw up the ID information.

    I've had incompatibilities with the use of Replay Protection in the past - I believe different vendors implement it in subtlely different ways, so you may want to avoid that to simplify matters.

    Also, the use of SHA1 in some versions of freeswan is buggy - I'm not sure what version of freeswan the linksys is using so it may be affected, so you may want to use MD5 just in case.

    A good source of information when trying to get freeswan working is the freeswan lists, try searching through some of the archives for the 'users' lists, that may help. http://www.freeswan.org/mail.html - if you have any more detailed logs that would be a help too (haven't yet looked at how much detail you can get from the linksys logs, that's another thing I will get round to).

  3. Nige

    Nige Network Guru Member

    One other thing: INVALID_EXCHANGE_TYPE may refer to an inconsistency between the configuration on either VPN device, and it's always a good idea to double-check that the settings on both ends of the tunnel agree.
  4. schwa13

    schwa13 Network Guru Member

    still working on it

    Thanks for the thoughts, I will give it another shot today. I was indeed using external WAN IP addressing exclusively, no FQDN or anything that uses DNS.

    I will try working on this later today again and will keep you updated!


Share This Page