[Swan] How to let "PLUTO_PEER_PROTOCOL" and "PLUTO_MY_PROTOCOL" to be 17 (UDP) ?

ChenHao earthlovepython at outlook.com
Sun Nov 1 23:02:39 UTC 2015


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: paul at nohats.ca
Date: Mon, 2 Nov 2015 06:39:41 +0900
To: earthlovepython at outlook.com

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 <earthlovepython at outlook.com> 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: swan at lists.libreswan.org
From: paul at nohats.ca
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: earthlovepython at outlook.com

See leftprotoport= and rightprotopprt= described in the ipsec.conf man page

Sent from my iPhone
On Nov 1, 2015, at 12:38, ChenHao <earthlovepython at outlook.com> 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
Swan at lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
 		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20151101/b6427018/attachment-0001.html>


More information about the Swan mailing list