[Openswan Users] Hash payload place for agressive mode

Rolando Zappacosta zappacor at yahoo.com.ar
Sun Feb 24 07:47:16 EST 2008

Hi all,

Yet another theory to (possibly) explain why I can't
connect to a Lucent VPN Gateway from my OpenSwan

I'm getting always INVALID_HASH_INFORMATION complains
from pluto and I could see, between other interesting
things, that the server (the Lucent's gateway) is
sending me back this ISAKMP packet after mine (the
first one):

Internet Security Association and Key Management
    Initiator cookie: F4B16542588CA2AE
    Responder cookie: 30DB5E384EBAA6E3
    Next payload: Security Association (1)
    Version: 1.0
    Exchange type: Aggressive (4)
    Flags: 0x00
        .... ...0 = Not encrypted
        .... ..0. = No commit
        .... .0.. = No authentication
    Message ID: 0x00000000
    Length: 308
    Security Association payload
        Next payload: Key Exchange (4)
        Payload length: 64
        Domain of interpretation: IPSEC (1)
        Situation: IDENTITY (1)
        Proposal payload # 1
            Next payload: NONE (0)
            Payload length: 52
            Proposal number: 1
            Protocol ID: ISAKMP (1)
            SPI Size: 8
            Proposal transforms: 1
            SPI: 0x30DB5E384EBAA6E3
            Transform payload # 4
                Next payload: NONE (0)
                Payload length: 36
                Transform number: 4
                Transform ID: KEY_IKE (1)
                Encryption-Algorithm (1): 3DES-CBC (5)
                Hash-Algorithm (2): SHA (2)
                Authentication-Method (3): PSK (1)
                Group-Description (4): Alternate
1024-bit MODP group (2)
                Life-Type (11): Seconds (1)
                Life-Duration (12): Duration-Value
    Key Exchange payload
        Next payload: Nonce (10)
        Payload length: 132
        Key Exchange Data (128 bytes / 1024 bits)
    Nonce payload
        Next payload: Identification (5)
        Payload length: 20
        Nonce Data
    Identification payload
        Next payload: Hash (8)
        Payload length: 12
        ID type: 1
        ID type: IPV4_ADDR (1)
        Protocol ID: Unused
        Port: Unused
        Identification data: <IPsecSERVER-IP>
    Hash payload
        Next payload: Vendor ID (13)
        Payload length: 24
        Hash Data
    Vendor ID:
        Next payload: NONE (0)
        Payload length: 28
        Vendor ID:

and I read the order in above packet should be:
ISAKMP header + hash payload + SA payload
and this is not the case here.

Could be Openswan is assuming the first payload is the
hash, while it's actually not, and checking it against
another one instead (the Security Association or the
Key Exchange in this case)?

Kind regards,

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

More information about the Users mailing list