Racoon: []: ERROR: the length in the isakmp header is too big.



  • i'm trying to move from 1.2.3-RC1 to 2.0. i'm using the same config as with 1.2.3-RC1. I didn't do an upgrade but manually re-did all of the config for 2.0. everything looks good but when i try to send data from the client, this message starts to repeat in the ipsec log:

    racoon: []: ERROR: the length in the isakmp header is too big.

    i've tried:
    decreasing the MTU in the client to 1360
    enabling/disabling ike fragmentation to 580 bytes
    enabling/disabling dead peer detection, deflate, ike failure notifications
    i tried both of my wan links incase it was something specific to one of them, same issue.

    here's the full log:

    
    Feb 21 20:34:22 	racoon: []: ERROR: the length in the isakmp header is too big.
    Feb 21 20:34:15 	racoon: []: ERROR: such policy does not already exist: "192.168.1.0/24[0] 192.168.2.160/32[0] proto=any dir=out"
    Feb 21 20:34:15 	racoon: []: ERROR: such policy does not already exist: "192.168.2.160/32[0] 192.168.1.0/24[0] proto=any dir=in"
    Feb 21 20:34:15 	racoon: []: INFO: IPsec-SA established: ESP 216.x.y.z[500]->67.x.y.z[500] spi=4286720205(0xff8228cd)
    Feb 21 20:34:15 	racoon: []: INFO: IPsec-SA established: ESP 216.x.y.z[500]->67.x.y.z[500] spi=226942663(0xd86dec7)
    Feb 21 20:34:15 	racoon: []: INFO: Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)
    Feb 21 20:34:15 	racoon: []: INFO: Adjusting my encmode UDP-Tunnel->Tunnel
    Feb 21 20:34:15 	racoon: []: INFO: no policy found, try to generate the policy : 192.168.2.160/32[0] 192.168.1.0/24[0] proto=any dir=in
    Feb 21 20:34:15 	racoon: []: INFO: respond new phase 2 negotiation: 216.x.y.z[4500]<=>67.x.y.z[54334]
    Feb 21 20:34:08 	racoon: []: INFO: purging spi=205254126.
    Feb 21 20:34:08 	racoon: []: INFO: received INITIAL-CONTACT
    Feb 21 20:34:08 	racoon: []: INFO: ISAKMP-SA established 216.x.y.z[4500]-67.x.y.z[54334] spi:5dbea7b9f13e9c7e:cab641bd65788698
    Feb 21 20:34:08 	racoon: []: INFO: NAT detected: ME PEER
    Feb 21 20:34:08 	racoon: []: INFO: NAT-D payload #1 doesn't match
    Feb 21 20:34:08 	racoon: []: INFO: Hashing 67.x.y.z[54334] with algo #2
    Feb 21 20:34:08 	racoon: []: INFO: NAT-D payload #0 doesn't match
    Feb 21 20:34:08 	racoon: []: INFO: Hashing 216.x.y.z[4500] with algo #2
    Feb 21 20:34:08 	racoon: []: INFO: NAT-T: ports changed to: 67.x.y.z[54334]<->216.x.y.z[4500]
    Feb 21 20:34:08 	racoon: []: INFO: Hashing 216.x.y.z[500] with algo #2
    Feb 21 20:34:08 	racoon: []: INFO: Hashing 67.x.y.z[54335] with algo #2
    Feb 21 20:34:08 	racoon: []: INFO: Adding remote and local NAT-D payloads.
    Feb 21 20:34:08 	racoon: []: INFO: Selected NAT-T version: RFC 3947
    Feb 21 20:34:08 	racoon: []: INFO: received Vendor ID: CISCO-UNITY
    Feb 21 20:34:08 	racoon: []: INFO: received Vendor ID: DPD
    Feb 21 20:34:08 	racoon: []: INFO: received Vendor ID: RFC 3947
    Feb 21 20:34:08 	racoon: []: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
    Feb 21 20:34:08 	racoon: []: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
    Feb 21 20:34:08 	racoon: []: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-01
    Feb 21 20:34:08 	racoon: []: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
    Feb 21 20:34:08 	racoon: []: INFO: begin Aggressive mode.
    Feb 21 20:34:08 	racoon: []: INFO: respond new phase 1 negotiation: 216.x.y.z[500]<=>67.x.y.z[54335]
    
    


  • Have you tried without NAT-T? That appears to be related, from some searching, would be good to confirm or deny that.



  • Not my original post, but I have the same symtoms. Confirming resolution: disabling NAT-T makes errors go away and packets flow thru the tunnel.

    Edit: Running 2010-03-24 snapshot, fresh install


Log in to reply