> > > The conclusion from all the above, is that on failure to add_sa with > > > offload, we may retry add_sa without offload. > > > But then again some users may want to engineer their systems to only > add > > supported SAs. They will not want to tolerate fallback to non-offload. > > > Maybe this could be another configuration option? > > > > not sure what would be a good solution. In some sense less knobs the > > beter! > > My intention is to make sure there is clear logging when add_sa failis. > > So the user know what failed. > > I did just: > - phase2alg=aes_gcm256-null > > And it doesn't work ofcourse. > > /var/log/secure shows: > Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1: initiating > Main Mode > Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1: transition > from state STATE_MAIN_I1 to state STATE_MAIN_I2 > Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1: > STATE_MAIN_I2: sent MI2, expecting MR2 > Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1: transition > from state STATE_MAIN_I2 to state STATE_MAIN_I3 > Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1: > STATE_MAIN_I3: sent MI3, expecting MR3 > Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1: Main mode > peer ID is ID_IPV4_ADDR: '192.168.7.11' > Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1: transition > from state STATE_MAIN_I3 to state STATE_MAIN_I4 > Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1: > STATE_MAIN_I4: ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 > integ=sha group=MODP2048} > Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #2: initiating > Quick Mode > PSK+ENCRYPT+TUNNEL+PFS+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ > ESN_NO {using isakmp#1 msgid:6f21bad0 proposal=defaults pfsgroup=MODP2048} > Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #2: ERROR: > netlink response for Get SA esp.9195dc7a@192.168.7.11 included errno 3: No > such process
I figured out why pluto doesn't complain about NEWSA failure... This line https://github.com/libreswan/libreswan/blob/master/programs/pluto/kernel_netlink.c#L474 quiets it because the expected response is NLMSG_NOOP. Do you know why this condition is so? If I remove the NOOP condition then it complains properly about failure to add: "myconn" #2: ERROR: netlink response for Add SA esp.fc8faa72@192.168.7.1 included errno 22: Invalid argument > Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #2: transition > from state STATE_QUICK_I1 to state STATE_QUICK_I2 > Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #2: > STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode > {ESP=>0x9195dc7a <0xfee4040d xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none > DPD=passive} > Jun 29 14:53:08 gen-l-vrt-103-005 pluto[28569]: initiate on demand from > 192.168.7.1:8 to 192.168.7.11:0 proto=1 because: acquire > Jun 29 14:53:08 gen-l-vrt-103-005 pluto[28569]: "myconn" #3: initiating > Quick Mode > PSK+ENCRYPT+TUNNEL+PFS+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ > ESN_NO {using isakmp#1 msgid:b52ce458 proposal=defaults pfsgroup=MODP2048} > Jun 29 14:53:08 gen-l-vrt-103-005 pluto[28569]: "myconn" #3: transition > from state STATE_QUICK_I1 to state STATE_QUICK_I2 > Jun 29 14:53:08 gen-l-vrt-103-005 pluto[28569]: "myconn" #3: > STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode > {ESP=>0x9cb505f5 <0x27cc5e2d xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none > DPD=passive} > > Apparently it was going for AES with HMAC-SHA1, which is not supported for > offload. > But the log doesn't indicate where the problem is or that > MSG_NEWSA/UPDATESA failed. > > dmesg warning reveals it: > [ 8852.735900] mlx5_core 0000:00:08.0 ens8: Cannot offload authenticated > xfrm states > _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev