Hi Paul:
>From /var/log/pluto.log, phase 1 is done. Phase 2 is failed due to "cannot
>respond to IPsec SA request because no connection". I analyzed log file, I
>think it is caused by "0/0" != "17/0" (see belowing highlighted log file). Can
>you please confirm ?
Thanks and regards
Hao Chen
"ip6.tun0" #113: STATE_MAIN_R3: sent MR3, ISAKMP SA established
{auth=PRESHARED_KEY cipher=oakley_3des_cbc_192 integ=md5 group=MODP1024}|
modecfg pull: noquirk policy:push not-client| phase 1 is done, looking for
phase 2 to unpend| unpending state #113| * processed 1 messages from
cryptographic helpers| next event EVENT_v1_RETRANSMIT in 4 seconds for #112|
next event EVENT_v1_RETRANSMIT in 4 seconds for #112| *received 172 bytes from
2607:f160:10:509:ce:ff2:0:3:500 on bond.2250 (port=500).....................|
decrypting 144 bytes using algorithm OAKLEY_3DES_CBC| NSS: do_3des init start|
NSS: do_3des init end| decrypted:| 01 00 00 14 32 ae 3b 2b e2 cf 9c e2 e6
38 0a d2| a3 4a 17 b3 0a 00 00 30 00 00 00 01 00 00 00 01| 00 00 00 24
01 03 04 01 40 06 7b 9f 00 00 00 18| 01 03 00 00 80 01 00 01 80 02 12 c0
80 04 00 01| 80 05 00 01 05 00 00 18 22 8e 22 71 85 11 14 ef| ee 5e cf
52 1f d0 e5 cb 99 0f 47 cb 05 00 00 18| 05 11 00 00 fd 6f 0d 30 1b b6 b4
19 00 00 00 00| 00 00 00 01 00 00 00 18 05 11 00 00 fd 1d 0d 30| 1b b6
b4 19 00 00 00 00 00 00 00 01 95 53 39 45| next IV: db 32 cd 21 90 84 1c
67| got payload 0x100 (ISAKMP_NEXT_HASH) needed: 0x502opt: 0x200030| ***parse
ISAKMP Hash Payload:| next payload type: ISAKMP_NEXT_SA| length: 20| got
payload 0x2 (ISAKMP_NEXT_SA) needed: 0x402opt: 0x200030| ***parse ISAKMP
Security Association Payload:| next payload type: ISAKMP_NEXT_NONCE|
length: 48| DOI: ISAKMP_DOI_IPSEC| got payload 0x400 (ISAKMP_NEXT_NONCE)
needed: 0x400opt: 0x200030| ***parse ISAKMP Nonce Payload:| next payload
type: ISAKMP_NEXT_ID| length: 24| got payload 0x20 (ISAKMP_NEXT_ID) needed:
0x0opt: 0x200030| ***parse ISAKMP Identification Payload (IPsec DOI):| next
payload type: ISAKMP_NEXT_ID| length: 24| ID type: ID_IPV6_ADDR|
Protocol ID: 17| port: 0| obj: fd 6f 0d 30 1b b6 b4 19 00 00 00 00
00 00 00 01| got payload 0x20 (ISAKMP_NEXT_ID) needed: 0x0opt: 0x200030|
***parse ISAKMP Identification Payload (IPsec DOI):| next payload type:
ISAKMP_NEXT_NONE| length: 24| ID type: ID_IPV6_ADDR| Protocol ID: 17|
port: 0| obj: fd 1d 0d 30 1b b6 b4 19 00 00 00 00 00 00 00 01|
removing 4 bytes of padding.....................| peer client is
fd6f:d30:1bb6:b419::1| peer client protocol/port is 17/0| our client is
fd1d:d30:1bb6:b419::1| our client protocol/port is 17/0"ip6.tun0" #113: the
peer proposed: fd1d:d30:1bb6:b419::1/128:0/0 -> fd6f:d30:1bb6:b419::1/128:0/0|
find_client_connection starting with ip6.tun0| looking for
fd1d:d30:1bb6:b419::1/128:17/0 -> fd6f:d30:1bb6:b419::1/128:17/0| concrete
checking against sr#0 fd1d:d30:1bb6:b419::1/128 -> fd6f:d30:1bb6:b419::1/128|
match_id a=2607:f160:10:509:ce:ff2:0:3|
b=2607:f160:10:509:ce:ff2:0:3| results matched| trusted_ca called with
a=(empty) b=(empty)| fc_try concluding with none [0]| fc_try ip6.tun0 gives
none| find_host_pair: comparing to 2607:f160:10:3e1:ce:10e:0:7:500
2607:f160:10:509:ce:ff2:0:3:500| find_host_pair: comparing to ::1:500 :::500|
find_host_pair: comparing to 172.16.162.40:500 198.226.45.30:500|
find_host_pair: comparing to 172.16.162.40:500 198.226.45.29:500|
find_host_pair: comparing to 172.16.162.40:500 172.24.252.40:500|
find_host_pair: comparing to 172.16.162.40:500 172.31.155.34:500|
find_host_pair: comparing to 2607:f160:10:3e1:ce:10e:0:7:500
2607:f160:0:2003::9:500| find_host_pair: comparing to
2607:f160:10:3e1:ce:10e:0:7:500 2607:f160:0:2003::c:500| checking hostpair
fd1d:d30:1bb6:b419::1/128 -> fd6f:d30:1bb6:b419::1/128 is not found|
concluding with d = none"ip6.tun0" #113: cannot respond to IPsec SA request
because no connection is known for
fd1d:d30:1bb6:b419::1/128===2607:f160:10:3e1:ce:10e:0:7<2607:f160:10:3e1:ce:10e:0:7>:17/0...2607:f160:10:509:ce:ff2:0:3<2607:f160:10:509:ce:ff2:0:3>:17/0===fd6f:d30:1bb6:b419::1/128|
complete v1 state transition with INVALID_ID_INFORMATION"ip6.tun0" #113:
sending encrypted notification INVALID_ID_INFORMATION to
2607:f160:10:509:ce:ff2:0:3:500| **emit ISAKMP Message:| initiator cookie:|
15 f1 9c 33 3b a1 81 d0| responder cookie:| d4 2f 9c 02 27 c4 e2 38|
next payload type: ISAKMP_NEXT_HASH| ISAKMP version: ISAKMP Version 1.0
(rfc2407)| exchange type: ISAKMP_XCHG_INFO| flags:
ISAKMP_FLAG_v1_ENCRYPTION| message ID: d1 31 bd 17| ***emit ISAKMP Hash
Payload:| next payload type: ISAKMP_NEXT_N| emitting 16 zero bytes of
HASH(1) into ISAKMP Hash Payload| emitting length of ISAKMP Hash Payload: 20|
***emit ISAKMP Notification Payload:| next payload type: ISAKMP_NEXT_NONE|
DOI: ISAKMP_DOI_IPSEC| protocol ID: 1| SPI size: 0| Notify Message
Type: INVALID_ID_INFORMATION
Subject: Re: [Swan] How to let "PLUTO_PEER_PROTOCOL" and "PLUTO_MY_PROTOCOL" to
be 17 (UDP) ?
From: [email protected]
Date: Mon, 2 Nov 2015 06:39:41 +0900
To: [email protected]
All those variables are informational! You should never try to change them!
They are filled in based on the IKE negotiation that happened.
17/0 is often used for only allowing l2tp packets with IPSec. If that
mismatches you need to think about what you are trying to do and reconfigure
the two endpoint to match their configuration.
You did not tell me what you want to accomplish so I don't know what is right
or what is wrong
Sent from my iPhone
On Nov 2, 2015, at 03:17, ChenHao <[email protected]> wrote:
Deal Paul:
I faced "0/0" is NOT "17/0" while handle "the
peer proposed" in quick mode (see previous email chain). So I guess I shall set
PLUTO_PEER_PROTOCOL.
My guess is really correct ? Can you please confirm ?
Thanks and regards
Hao Chen
CC: [email protected]
From: [email protected]
Subject: Re: [Swan] How to let "PLUTO_PEER_PROTOCOL" and "PLUTO_MY_PROTOCOL" to
be 17 (UDP) ?
Date: Sun, 1 Nov 2015 17:38:49 +0900
To: [email protected]
See leftprotoport= and rightprotopprt= described in the ipsec.conf man page
Sent from my iPhone
On Nov 1, 2015, at 12:38, ChenHao <[email protected]> wrote:
Hi All:
/var/log/pluto.log writes:=========================| peer client is
fd6f:d30:1bb6:b419::1
| peer client protocol/port is 17/0
| our client is
fd1d:d30:1bb6:b419::1
| our client protocol/port is 17/0
"ip6.tun0" #113: the
peer proposed: fd1d:d30:1bb6:b419::1/128:0/0
-> fd6f:d30:1bb6:b419::1/128:0/0
| find_client_connection
starting with ip6.tun0
| looking for
fd1d:d30:1bb6:b419::1/128:17/0 -> fd6f:d30:1bb6:b419::1/128:17/0
Because "0/0" is NOT "17/0", find_client_connection() return NULL. As a result,
quick_inI1_outR1_authtail() fail "cannot respond to IPsec SA request because no
connection is known for" && "sending encrypted notification
INVALID_ID_INFORMATION to"
Question: how to set local protocol to 17 (UDP) instead of 0?
Corresponding source code:==================quick_inI1_outR1_authtail(){……
libreswan_log("the peer proposed: %s:%d/%d -> %s:%d/%d",
s1, c->spd.this.protocol,
c->spd.this.port, ç== “spd” is “struct spd_route”
d1, c->spd.that.protocol, c->spd.that.port);……}
quick_inI1_outR1_authtail()
calls find_client_connection() find_client_connection(){….
DBG_log(" looking for %s:%d/%d -> %s:%d/%d",
s1, our_protocol,
our_port,
d1, peer_protocol,
peer_port);….
if (samesubnet(&sr->this.client, our_net) &&
samesubnet(&sr->that.client, peer_net) &&
sr->this.protocol
== our_protocol && ç== Does NOT match. “sr” is “struct spd_route”. As a
result, failed.
(!sr->this.port ||
sr->this.port == our_port) &&
(sr->that.protocol == peer_protocol) &&
(!sr->that.port ||
sr->that.port == peer_port)) {
passert(oriented(*c));
if (routed(sr->routing))
return c; ç ==
We expect return here, but ….
unrouted = c;
}….}
“spd.this.protocol” is same as “sr->this.protocol”
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
