[Swan] IPv6 host-to-host using klips

Paul Wouters paul at nohats.ca
Fri Oct 9 18:31:15 UTC 2015


On Fri, 9 Oct 2015, Erik Andersson wrote:

> conn mytunnel
>    left=2001:470:dc8c:1000::28:60
>    right=2001:470:dc8c:1000::28:70
>    connaddrfamily=ipv6
>    authby=secret
>    auto=add

> When I try to bring up the tunnel I get the following output:

> On host 28:60:

> [root at vpn-f1 ~]# ipsec auto --up mytunnel

> 004 "mytunnel" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode 
> {ESP=>0x19bf43c9 <0x291c2985 xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none 
> DPD=passive}

So that's good. The tunnel came up.

> On host 28:70:
>
> [root at vpn-f1 ~]# ipsec auto --up mytunnel
> 002 "mytunnel" #3: initiating Quick Mode

It detected the tunnel was already up, so it is doing a rekey of phase2
only:

> PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW 
> {using isakmp#1 msgid:bc8dedb6 proposal=defaults 
> pfsgroup=OAKLEY_GROUP_MODP2048}
> 117 "mytunnel" #3: STATE_QUICK_I1: initiate
> 010 "mytunnel" #3: STATE_QUICK_I1: retransmission; will wait 500ms for 
> response
> 010 "mytunnel" #3: STATE_QUICK_I1: retransmission; will wait 1000ms for 
> response

> 031 "mytunnel" #3: max number of retransmissions (8) reached STATE_QUICK_I1. 
> No acceptable response to our first Quick Mode message: perhaps peer likes no 
> proposal

but failing. What does the pluto log on the other end say when this
happens?

> If I use netkey instead of klips the tunnel is successfully setup. Am I 
> missing any necessary configuration options for klips?

Odd. No you are not missing anything.

> Another thing. When I browsed the archives I noticed the post 
> https://lists.libreswan.org/pipermail/swan/2015/001168.html. Don't know if 
> that ever got resolved. This is just a long shot but we experienced memory 
> leak issues with pluto when there was a PFS group mismatch on a large number 
> of tunnels (approx. 40). The following patch mitigated our issue:
>
> --- a/programs/pluto/ikev1_quick.c
> +++ b/programs/pluto/ikev1_quick.c
> @@ -2252,6 +2252,10 @@ static void quick_inI1_outR1_cryptocontinue1(
>
> complete_v1_state_transition(&qke->qke_md, e);
>                                release_any_md(&qke->qke_md);
>                        }
> +               } else if (e == STF_FAIL + NO_PROPOSAL_CHOSEN) {
> +                       /* No PFS */
> +                       if(md)
> +                               release_md(qke->qke_md);

That looks reasonable, but we should take a closer look. Since this is
in inI1_outR1, any STF_FAIL should cause us to delete the entire state.
So perhaps there is a better place where this can be deleted to prevent
the memory loss more generally. For example, an STF_FATAL might also
need to release the md to prevent the leak.

Adding Hugh to the CC: since he's looked this code last.

>                }
>        }
>        reset_cur_state();
> @@ -2300,6 +2304,10 @@ static void quick_inI1_outR1_cryptocontinue2(
>                        complete_v1_state_transition(&dh->dh_md, e);
>                        release_any_md(&dh->dh_md);
>                }
> +       } else if (e == STF_FAIL + NO_PROPOSAL_CHOSEN) {
> +               /* No PFS */
> +               if(dh->dh_md)
> +                       release_md(dh->dh_md);

same here.

Paul


More information about the Swan mailing list