[prev in list] [next in list] [prev in thread] [next in thread] 

List:       strongswan-users
Subject:    [strongSwan] INVALID_MESSAGE_IDs (duplicate) from Checkpoint NG
From:       smcdermott () questra ! com (Scott Mcdermott)
Date:       2005-03-10 13:45:48
Message-ID: 20050310124551.GT30898 () questra ! com
[Download RAW message or body]

List members,

I have recently replaced a KAME Racoon setup with a
Strongswan 2.4.0a setup, and most of my tunnels now work
fine again after the switch.

However, I am now having a new problem with a Checkpoint
FW-1 partner, where the old Racoon system worked fine
before.  My partner tells me the exact version is listed as
"Checkpoint NG With Application Intelligence (R54) build 289."

I believe the ISAKMP SA is established fine, but Phase 2 is
where we are going wrong.  Over and over again in the logs I
get the following message (sanitized slightly):

    | *received 300 bytes from 1.2.3.4:500 on eth3
    | **parse ISAKMP Message:
    |    initiator cookie:
    |   bf 80 db 19  5e 16 d3 df
    |    responder cookie:
    |   de 59 27 e6  9d c8 88 fd
    |    next payload type: ISAKMP_NEXT_HASH
    |    ISAKMP version: ISAKMP Version 1.0
    |    exchange type: ISAKMP_XCHG_QUICK
    |    flags: ISAKMP_FLAG_ENCRYPTION
    |    message ID:  f8 48 24 6f
    |    length: 300
    | ICOOKIE:  bf 80 db 19  5e 16 d3 df
    | RCOOKIE:  de 59 27 e6  9d c8 88 fd
    | peer:  ca 36 62 02
    | state hash entry 9
    | state object not found
    | ICOOKIE:  bf 80 db 19  5e 16 d3 df
    | RCOOKIE:  de 59 27 e6  9d c8 88 fd
    | peer:  ca 36 62 02
    | state hash entry 9
    | state object #17 found, in STATE_MAIN_R3
    "remote-lan" #17: Quick Mode I1 message is unacceptable because it uses a \
previously used Message ID 0x6f2448f8 (perhaps this is a duplicated packet)  \
"remote-lan" #17: sending encrypted notification INVALID_MESSAGE_ID to 1.2.3.4:500  | \
**emit ISAKMP Message:  |    initiator cookie:
    |   bf 80 db 19  5e 16 d3 df
    |    responder cookie:
    |   de 59 27 e6  9d c8 88 fd
    |    next payload type: ISAKMP_NEXT_HASH
    |    ISAKMP version: ISAKMP Version 1.0
    |    exchange type: ISAKMP_XCHG_INFO
    |    flags: ISAKMP_FLAG_ENCRYPTION
    |    message ID:  b0 b3 cc 74
    | ***emit ISAKMP Hash Payload:
    |    next payload type: ISAKMP_NEXT_N
    | emitting 20 zero bytes of HASH into ISAKMP Hash Payload
    | emitting length of ISAKMP Hash Payload: 24
    | ***emit ISAKMP Notification Payload:
    |    next payload type: ISAKMP_NEXT_NONE
    |    DOI: ISAKMP_DOI_IPSEC
    |    protocol ID: 1
    |    SPI size: 0
    |    Notify Message Type: INVALID_MESSAGE_ID
    | emitting 0 raw bytes of spi into ISAKMP Notification Payload
    | spi
    | emitting length of ISAKMP Notification Payload: 12
    | HASH computed:
    | last Phase 1 IV:  [hex]
    | computed Phase 2 IV:
    | encrypting:
    | emitting 12 zero bytes of encryption padding into ISAKMP Message
    | encrypting using OAKLEY_AES_CBC
    | next IV:  [hex]
    | emitting length of ISAKMP Message: 76
    | sending 76 bytes for ISAKMP notify through eth3 to 1.2.3.4:500:
    | next event EVENT_SA_REPLACE in 385 seconds for #9

This same tunnel worked fine with the KAME racoon software,
but Strongswan does not seem to like it.  I have had the
remote end break the tunnel, remove all SAs manually and
re-instantiate it from scratch; same issue persists.

I've searched around for help and get mostly a bunch of
broken links to old freeswan archives; I can't seem to find
any real information on this problem or what might cause it.

Is anyone successfully doing a net-to-net tunnel with a
Checkpoint NG on the remote end? What might cause the
duplicate message ID to be sent, and why does Racoon seem to
allow this behavior, but Strongswan does not?  Is there
anything I can do about this or should I accept that it does
not work and figure out a workaround (like trying to run
Racoon only for that tunnel, or possibly use manual keying?)

Any information is greatly appreciated.  Thanks.


[prev in list] [next in list] [prev in thread] [next in thread]