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]
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
