[Swan] [libreswan] Mac OS IKEv2 missing payload(s) (ISAKMP_NEXT_v2AUTH) (#47)

Paul Wouters paul at nohats.ca
Tue Feb 23 21:53:06 UTC 2016


On Mon, 22 Feb 2016, Jakub wrote:

> I am trying to configure Mac OS IKEv2 with libreswan (v3.13 or v3.16) using X.509 certificates on both sides.
> After adding ike=3des-sha1;modp1024 to v3.16 config (apparently the default has changed) and using Remote ID (the CN of server
> cert) and Local ID (the CN of client cert) I could get as far as server sending cert and client sending it's own cert back in the
> response. Server than says missing payload(s) (ISAKMP_NEXT_v2AUTH):

Most often, a missing payload means the response is an "error response"
and then usually there is a notify payload describing what is wrong.
But that's not the case here:

> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    exchange type: ISAKMP_v2_AUTH (0x23)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: ISAKMP_FLAG_v2_IKE_INIT (0x8)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    message ID:  00 00 00 01
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 364 (0x16c)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |  processing version=2.0 packet with exchange type=ISAKMP_v2_AUTH (35)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | I am receiving an IKE Request
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | I am the IKE SA Original Responder

So IKE_INIT request came in, you responded, then an IKE_AUTH request
came in. So far so good....

> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |   ICOOKIE:  52 7c 82 69  58 e1 5c ca
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |   RCOOKIE:  c8 2c 93 b8  13 3a 31 95
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | found hash chain 4
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | parent v2 peer and cookies match on #3
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | v2 state object #3 found, in STATE_PARENT_R1
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | found state #3

We found the state.

> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Unpacking clear payload for svm: respond to IKE_AUTH
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2SK)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | ***parse IKEv2 Encryption Payload:
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2IDi (0x23)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 336 (0x150)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2SK (len=336)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | selected state microcode respond to IKE_AUTH
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing connection "RoadWarrior-IKEv2"[2] 89.100.95.78
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now lets proceed with state specific processing
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | calling processor respond to IKE_AUTH
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing connection "RoadWarrior-IKEv2"[2] 89.100.95.78

> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | calculated auth:  f3 0f 49 7d  10 10 79 cd  78 71 c2 20
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |   provided auth:  f3 0f 49 7d  10 10 79 cd  78 71 c2 20
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | authenticator matched

Auth on packet ok.

> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2IDi)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Identification Payload:
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2N (0x29)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 33 (0x21)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    id_type: ID_USER_FQDN (0x3)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2IDi (len=33)

Read the first payload, which was the IDi

> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2N)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Notify Payload:
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2N (0x29)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 8 (0x8)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Protocol ID: PROTO_RESERVED (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    SPI size: 0 (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Notify Message Type: v2N_INITIAL_CONTACT (0x4000)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2N (len=8)

Read initial contact notify payload.

> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2N)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Notify Payload:
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2IDr (0x24)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 8 (0x8)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Protocol ID: PROTO_RESERVED (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    SPI size: 0 (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Notify Message Type: v2N_MOBIKE_SUPPORTED (0x400c)

mobike notify

> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2N (len=8)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2IDr)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Identification Payload:
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2CP (0x2f)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 37 (0x25)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    id_type: ID_FQDN (0x2)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2IDr (len=37)

IDr payload.

> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2CP)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Configuration Payload:
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2N (0x29)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 36 (0x24)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    ikev2_cfg_type: IKEv2_CP_CFG_REQUEST (0x1)

CP request payload.

> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2CP (len=36)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2N)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Notify Payload:
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2N (0x29)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 8 (0x8)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Protocol ID: PROTO_RESERVED (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    SPI size: 0 (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Notify Message Type: v2N_ESP_TFC_PADDING_NOT_SUPPORTED (0x400a)

another notify payload.

> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2N (len=8)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2N)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Notify Payload:
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2SA (0x21)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 8 (0x8)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Protocol ID: PROTO_RESERVED (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    SPI size: 0 (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Notify Message Type: v2N_NON_FIRST_FRAGMENTS_ALSO (0x400b)

another notify.

> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2N (len=8)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2SA)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Security Association Payload:

Then the SA payload, TSi/TSr payloads

> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2TSi (0x2c)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 40 (0x28)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2SA (len=40)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2TSi)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Traffic Selector Payload:
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2TSr (0x2d)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 64 (0x40)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    number of TS: 2 (0x2)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2TSi (len=64)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2TSr)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Traffic Selector Payload:
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2NONE (0x0)

Then it says this is the last payload.

> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 64 (0x40)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    number of TS: 2 (0x2)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2TSr (len=64)
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: "RoadWarrior-IKEv2"[2] 89.100.95.78 #3: missing payload(s) (ISAKMP_NEXT_v2AUTH). Mes
> sage dropped.
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | ikev2_parent_inI2outR2_tail returned STF_FAIL with v2N_INVALID_SYNTAX
> Feb 22 16:12:42 dublin.dev.router pluto[5691]: | #3 complete v2 state transition from STATE_PARENT_R1 with v2N_INVALID_SYNTAX

And we feel there is a missing AUTH payload. And if I read:
https://tools.ietf.org/html/rfc7296#section-1.2

I don't see any valid IKE_AUTH request that would not have an AUTH
payload. So it looks like we are rejecting for the right reason.

> and after few retries fails. I don't know how to debug it on Mac OS since logs are no longer written to racoon.log.

So that must mean the new iOS code is used. I'll forward this message
to an Apple contact and see what they say. I've CC:ed the swan list
because we don't really use github for bugs/emails, so please move
this discussion there.

Paul

> conn %default
>     # This may come handy if fragmented IP packets are dropped or DF'ed
>     ike_frag=yes
>
>     # x509
>     authby=rsasig
>     leftcert="dublin.dev.vpn.example.com - example.com"
>     leftsendcert=always
>     leftid=%fromcert
>     rightid=%fromcert
>
>     # Perfect Forward Secrecy - off since M$ and Apple have it disabled by default, wonder why...
>     pfs=no
>     # we cannot rekey for %any, let client rekey
>     rekey=no
>
>     # Timeouts
>     ## Set ikelifetime and keylife to same defaults windows has
>     ikelifetime=8h
>     keylife=1h
>     rekeymargin=3m
>     keyingtries=3
>
>     # Dead node detection
>     dpddelay=4
>     dpdtimeout=30
>     dpdaction=clear
>
>     # ID
>     left=%eth0
>     right=%any
>
>     # listen for auto keying connections
>     auto=add
> 
> conn RoadWarrior-IKEv2
>     ikev2=insist
>     ike=3des-sha1;modp1024
>     rightaddresspool=10.224.1.97-10.224.1.128
>     # Subnet that is accessible for the client (NOTE: leftsubnets= does not work with rightaddresspool...)
>     leftsubnet=10.0.0.0/8
> 
> conn RoadWarrior-IKEv1-L2TP
>     ikev2=no
>     leftprotoport=udp/l2tp
>     rightprotoport=udp/%any
> 
> conn v6neighbor-hole-in
>     left=::1
>     leftsubnet=::0/0
>     leftprotoport=58/34560
>     rightprotoport=58/34816
>     rightsubnet=::0/0
>     right=::0
>     connaddrfamily=ipv6
>     authby=never
>     type=passthrough
>     auto=route
>     priority=1
> 
> conn v6neighbor-hole-out
>     left=::1
>     leftsubnet=::0/0
>     leftprotoport=58/34816
>     rightprotoport=58/34560
>     rightsubnet=::0/0
>     right=::0
>     connaddrfamily=ipv6
>     authby=never
>     type=passthrough
>     auto=route
>     priority=1
> 
> Thanks you.
> 
>> Reply to this email directly or view it on GitHub.[AC3V-QZzu5Ul-rtCP2EynYO7hdDPJZlWks5pmzaggaJpZM4HfwV3.gif]
> 
> 
>


More information about the Swan mailing list