Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
1974 Views 11 Replies Latest reply: Feb 24, 2012 1:00 PM by sliedl RSS 1 2 Previous Next
billcarlson Newcomer 8 posts since
Feb 24, 2012
Currently Being Moderated

Feb 24, 2012 10:45 AM

VPN setup to remote gateway, fails with "INVALID_ID_INFO"

Hello all,

 

New to sidewinder products, I'm trying to setup a basic gateway-to-gateway VPN. Remote gateway is openswan-based. Local firewall is version 8.2.

 

Doing simple PSK authentication, here's what I see in audit/debug mode:

 

2012-02-24 10:06:37 -0500 f_isakmp_daemon a_vpn t_error p_major

pid: 5365 logid: 0 cmd: 'ikmpd' hostname: xxxx

vpn_name: !DYNAMIC! cky_i: c248ee7b3d039628 cky_r: 2dfdf6aede62fe3b

local_gw: 64.250.185.67 remote_gw: 69.66.104.151

information: [detailed info]

  [delete]

    protocol: IKE

    spi(16): |c248ee7b3d0396282dfdf6aede62fe3b|

  [error]

    MAIN_MODE exchange terminated - MAIN_MODE exchange processing failed

  [error]

    MAIN_MODE processing encountered error, exchange aborted

  [error]

    No IKE (phase 1) policy configured for peer

    [local gateway]

      IPV4_ADDR-64.250.185.67:500

    [remote gateway]

      IPV4_ADDR-69.66.104.151:500

    [remote identity]

      IPV4_ADDR-69.66.104.151:500

  [notify]

    protocol: IKE, type: INVALID_ID_INFO

[MAIN_MODE]

  VPN: !DYNAMIC!, CKY_I: |c248ee7b3d039628|, CKY_R: |2dfdf6aede62fe3b|,

  references: 1

  [state info]

    init/resp: RESPONDER, condition: DYING,

    state_mask: ACL_CHECK_PASSED|RATE_LIMIT|REMOTE, state: SA_SETUP

  [retry info]

    counter: 1, num_trans: 1, total_time: 3, total_deviation: 0,

    timestamp_out: 1330095995, timestamp_in: 1330095997

  [local gateway] id_type: IPV4_ADDR(1), id_string: 64.250.185.67, id_proto: 0,

    id_port: 500, id_data: |40fab943|

  [remote gateway] id_type: IPV4_ADDR(1), id_string: 69.66.104.151,

    id_proto: 0, id_port: 500, id_data: |45426897|

  [exchange policy]

    protocol: IKE, options: [INITIAL_CONTACT|NO_STRICT_ID_MATCHING|NAT_T],

    version: 1, local authentication: PRE_SHARED_KEY,

...(cont

 

2012-02-24 10:06:37 -0500 f_isakmp_daemon a_vpn t_error p_major

pid: 5365 logid: 0 cmd: 'ikmpd' hostname: xxxx

vpn_name: !DYNAMIC! cky_i: c248ee7b3d039628 cky_r: 2dfdf6aede62fe3b

local_gw: 64.250.185.67 remote_gw: 69.66.104.151

information: ...(cont)...

    remote authentication: PRE_SHARED_KEY, encryption: 3DES, integ: SHA1,

    DH group: 2

  [IKE info]

    allocations: 0

    [local identity]

      id_type: IPV4_ADDR(1), id_string: 64.250.185.67, id_proto: 0, id_port: 0,

      id_data: |40fab943|

    vendor ids: NATT_RFC|NATT_DRAFT3|NATT_DRAFT2B

    [chosen proposal]

      protocol: IKE

        protocol: IKE, options: [INITIAL_CONTACT|NO_STRICT_ID_MATCHING|NAT_T],

        version: 1, local authentication: PRE_SHARED_KEY,

        remote authentication: PRE_SHARED_KEY, encryption: 3DES, integ: SHA1,

        DH group: 2

 

 

 

I've verified the IDs listed match on the remote firewall, any pointers to what else to check?

 

Thanks in advance.

 

Message was edited by: billcarlson on 2/24/12 10:45:39 AM CST
  • McAfee SME 40 posts since
    Nov 4, 2009

    If you have not done so already, set the ISAKMP server to audit verbosely (Network - VPN Configuration - ISAKMP - Audit Level). This should tell us exactly what is failing with the negotiation.

     

    In addition to the IDs, also make sure that the encryption algorithms match, and that the local/remote networks also match.

  • sliedl McAfee SME 535 posts since
    Nov 3, 2009

    What do you have configured for the Remote Identity in the 'Remote Authentication' tab of this VPN definition?  Gateway IP address or an ID?

     

    The other side is sending its external IP as an identity.  Do you have something else selected for a Remote Identity in this tunnel?

  • sliedl McAfee SME 535 posts since
    Nov 3, 2009

    Put 'localhost' as the 'Local identity value' in the Local Authentication tab and see if that works.  You may be trying to build the tunnel with a different external IP (from your firewall) than what the firewall is using there for its local ID (64.250.185.67).

  • PhilM Champion 528 posts since
    Jan 7, 2010

    Sam jumped in before me as I was going to say the same thing.

     

    In addition, can you find out from the other end what it is unhappy about?

     

    You've included the log entry which says "INVALID_ID_INFO", but it doesn't appear to say which element is causing it distress.

     

    If you disable the "Enable initial contact", this may present the opportunity for the other end to try and initiate the tunnel. If you've then implemented rdestics recommendation of increasing the verbosity of the logs on your Firewall you should have greater visibility of the values being transmitted between the two Firewalls, what's being sent and what the other end is expecting to be sent.

     

    -Phil.

     

    Message was edited by: PhilM on 24/02/12 17:31:32 GMT
  • sliedl McAfee SME 535 posts since
    Nov 3, 2009

    The remote side is saying this is its identity:

    [remote identity]

       IPV4_ADDR-69.66.104.151:500


    We have this configured for his identity though:

       IPV4_ADDR-69.66.104.151

     

    There is no :500 after our identity.  The strings do not match.  I think this could be causing the problem.  I tested this here and got the 'same' type of error message, except I had to use the wrong IP address as my identity on one side (because I couldn't get one of the firewall to send 'my.ip.address:500' as my identity).  I received the same error you first pasted here.

1 2 Previous Next

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 5 points
  • Helpful Answers - 3 points