Hi Paul, I tried setting the dpd parameters as suggested shown below.
conn radcert ikev2=yes left=10.196.175.174 leftsubnet=10.196.175.174/32 leftprotoport=17/1812 right=10.196.176.11 rightsubnet=10.196.176.11/32 rightprotoport=17/1812 auto=ondemand ike=aes256-sha256;dh14 phase2=esp phase2alg=aes256-sha1;modp2048 pfs=yes authby=secret type=tunnel esn=no rekey=yes salifetime=300s ikelifetime=3600s dpddelay=30s dpdtimeout=60s dpdaction=hold As an FYI, there is no ESP traffic flowing much in the tunnel. Still the tunnel gets torn down from Libreswan. 2020-11-24T22:07:16.071632+00:00 [localhost] sshd[3367]: pam_authp(sshd:setcred): pam_sm_setcred: started 2020-11-24T22:07:43.863183+00:00 [localhost] pluto[3151]: "radcert" #2: Neither IKEv1 nor IKEv2 allowed: ENCRYPT+TUNNEL 2020-11-24T22:12:10.863542+00:00 [localhost] pluto[3151]: "radcert" #2: deleting state (STATE_V2_IPSEC_I) and sending notification 2020-11-24T22:12:10.863575+00:00 [localhost] pluto[3151]: "radcert" #2: ESP traffic information: in=73B out=96B 2020-11-24T22:12:10.868489+00:00 [localhost] pluto[3151]: expire unused parent SA #1 "radcert" 2020-11-24T22:12:10.868521+00:00 [localhost] pluto[3151]: "radcert" #1: ISAKMP SA expired (LATEST!) 2020-11-24T22:12:10.868525+00:00 [localhost] pluto[3151]: "radcert" #1: deleting state (STATE_PARENT_I3) and sending notification 2020-11-24T22:12:10.872568+00:00 [localhost] pluto[3151]: packet from 10.196.175.174:500: ISAKMP_v2_INFORMATIONAL message response has no matching IKE SA 2020-11-24T22:12:10.872582+00:00 [localhost] pluto[3151]: packet from 10.196.175.174:500: ISAKMP_v2_INFORMATIONAL message response has no matching IKE SA 2020-11-24T22:13:41.983279+00:00 [localhost] sshd[3483]: PAM unable to resolve symbol: pam_sm_authenticate Any idea? Thanks, Balaji On Tue, Nov 24, 2020 at 4:28 PM Paul Wouters <[email protected]> wrote: > On Tue, 24 Nov 2020, Balaji Thoguluva wrote: > > > I am using the below configuration with an intent to do IPsec rekey > initiated from Libreswan. > > > > conn radcert > > > dpddelay=0s > > dpdtimeout=0s > > dpdaction=hold > > don't set these to 0! That means whenever the code checks it deems your > connection is down. > > timeout is time time elapsed for no responses before the tunnel is > deemed down. RFCs say it should never be less than 60s, but it is > possible to set this shorter. > > delay is the time between probes, if the connection is idle. This should > also not be too short. > > Remember, if your link is busy and congested, if a dpd packet gets > dropped it counts as failure towards the timeout period. If you > timeout on a working connection due to congestion, you will have > a hard time getting the connection up - it will also drop packets > for the setup of the new tunnel. > > Try dpddelay=30s and dpdtimeout=60s > > Paul >
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
