add leftprotoport=17/0 and rightprotoport=17/0 to your connection. Note that means the other end wants to do L2TP/IPsec so you would also need xl2tpd for that. Unless the other end is misconfigured. Without you telling what the goal is, I cannot say which endpoint is wrong.
Sent from my iPhone > On Nov 2, 2015, at 08:02, ChenHao <[email protected]> wrote: > > 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
