Hello i had the problem with the disconnect in 3.9xx ? I changed to 4.1 and change the config. Now it is working. Here is the part from config
-- fragmentation=yes nat-keepalive=yes leftmodecfgserver=yes modecfgpull=yes modecfgdns=172.20.129.150,8.8.8.8 leftsubnet=0.0.0.0/0 rekey=no --- -----Ursprüngliche Nachricht----- Von: Swan <[email protected]> Im Auftrag von [email protected] Gesendet: Freitag, 22. Januar 2021 13:06 An: [email protected] Betreff: Swan Digest, Vol 97, Issue 17 Send Swan mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.libreswan.org/mailman/listinfo/swan or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Swan digest..." Today's Topics: 1. Re: disconnect after 3600s (Ant?nio Silva) ---------------------------------------------------------------------- Message: 1 Date: Fri, 22 Jan 2021 12:06:14 +0000 From: Ant?nio Silva <[email protected]> To: Michael Schwartzkopff <[email protected]> Cc: [email protected] Subject: Re: [Swan] disconnect after 3600s Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" I just change my configuration adding ?rekey=yes?, waiting for the next hour do check the results. -- Saludos / Regards / Cumprimentos Ant?nio Silva > On 22 Jan 2021, at 12:02, Ant?nio Silva <[email protected]> wrote: > > Hi, > > I?m having the same issue, after upgrading the server side to version 4.1, > every hour the tunnel disconnects, restarting the client side only makes it > work again. > > > Here is the logs from the server side when the tunnel is reconnecting after > an 1h: > > Jan 22 12:37:36 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #93: > initiating IKEv1 Main Mode connection to replace #89 Jan 22 12:37:36 > sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #93: sent Main Mode > request, replacing #89 Jan 22 12:37:36 sol pluto[24350]: "tunnel8"[10] > 95.61.168.133 #94: responding to Main Mode from unknown peer > 95.61.168.133:500 Jan 22 12:37:36 sol pluto[24350]: "tunnel8"[10] > 95.61.168.133 #94: sent Main Mode R1 Jan 22 12:37:36 sol pluto[24350]: > "tunnel8"[10] 95.61.168.133 #94: sent Main Mode R2 Jan 22 12:37:36 sol > pluto[24350]: "tunnel8"[10] 95.61.168.133: queuing pending IPsec SA > negotiating with 95.61.168.133 IKE SA #93 "tunnel8"[10] 95.61.168.133 Jan 22 > 12:37:36 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #94: Peer ID is > ID_IPV4_ADDR: '192.168.1.2' > Jan 22 12:37:36 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #94: IKE > SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 > integ=HMAC_SHA2_256 group=MODP2048} Jan 22 12:37:36 sol pluto[24350]: > "tunnel8"[10] 95.61.168.133 #94: XAUTH: Sending Username/Password request > (MAIN_R3->XAUTH_R0) Jan 22 12:37:36 sol pluto[24350]: "tunnel8"[10] > 95.61.168.133 #94: XAUTH: password file authentication method requested to > authenticate user '[email protected] <mailto:[email protected]>' > Jan 22 12:37:36 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #94: XAUTH: > password file (/etc/ipsec.d/passwd) open. > Jan 22 12:37:36 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #94: > XAUTH: success user([email protected] > <mailto:[email protected]>:(null)) > Jan 22 12:37:36 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #94: > XAUTH: User [email protected] <mailto:[email protected]>: > Authentication Successful Jan 22 12:37:36 sol pluto[24350]: > "tunnel8"[10] 95.61.168.133 #94: XAUTH: xauth_inR1(STF_OK) Jan 22 > 12:37:36 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #94: IKE SA > established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 > group=MODP2048} Jan 22 12:37:36 sol pluto[24350]: | pool > 192.168.20.2-192.168.20.2: growing address pool from 0 to 1 Jan 22 > 12:37:36 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #94: > modecfg_inR0(STF_OK) Jan 22 12:37:36 sol pluto[24350]: "tunnel8"[10] > 95.61.168.133 #94: sent ModeCfg reply, expecting Ack {auth=PRESHARED_KEY > cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048} Jan 22 12:37:36 sol > pluto[24350]: "tunnel8"[10] 95.61.168.133 #93: STATE_MAIN_I1: retransmission; > will wait 0.5 seconds for response Jan 22 12:37:37 sol pluto[24350]: > "tunnel8"[10] 95.61.168.133 #93: sent Main Mode I2 Jan 22 12:37:37 sol > pluto[24350]: "tunnel8"[10] 95.61.168.133 #93: sent Main Mode I3 Jan 22 > 12:37:37 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #93: Peer ID is > ID_IPV4_ADDR: '192.168.1.2' > Jan 22 12:37:37 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #93: IKE > SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 > integ=HMAC_SHA2_256 group=MODP2048} Jan 22 12:37:37 sol pluto[24350]: > "tunnel8"[10] 95.61.168.133 #93: XAUTH: Sending Username/Password > request (MAIN_I4->XAUTH_R0) Jan 22 12:37:37 sol pluto[24350]: > "tunnel8"[10] 95.61.168.133 #93: ignoring informational payload > CERTIFICATE_UNAVAILABLE, msgid=00000000, length=12 Jan 22 12:37:37 sol > pluto[24350]: "tunnel8"[10] 95.61.168.133 #93: received and ignored > notification payload: CERTIFICATE_UNAVAILABLE Jan 22 12:42:06 sol > pluto[24350]: "tunnel8"[10] 95.61.168.133 #89: deleting state > (STATE_MODE_CFG_R1) aged 3600.266987s and sending notification Jan 22 > 12:42:06 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #90: deleting > state (STATE_QUICK_R2) aged 3600.089852s and sending notification Jan > 22 12:42:06 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #90: ESP > traffic information: in=11MB out=30MB [email protected] > <mailto:[email protected]> > Jan 22 12:42:06 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #90: Warning: > XAUTH username changed from '' to 'asilvaptremote.local' > Jan 22 12:42:06 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #93: > ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x3e9fbbf6) not found (maybe > expired) Jan 22 12:42:06 sol pluto[24350]: ignoring found existing connection > instance "tunnel8"[10] 95.61.168.133 that covers kernel acquire with IKE > state #93 and IPsec state #0 - due to duplicate acquire? > Jan 22 12:42:36 sol pluto[24350]: existing bare shunt found - refusing > to add a duplicate Jan 22 12:42:36 sol pluto[24350]: ignoring found existing > connection instance "tunnel8"[10] 95.61.168.133 that covers kernel acquire > with IKE state #93 and IPsec state #0 - due to duplicate acquire? > Jan 22 12:42:36 sol pluto[24350]: existing bare shunt found - refusing > to add a duplicate Jan 22 12:42:36 sol pluto[24350]: ignoring found existing > connection instance "tunnel8"[10] 95.61.168.133 that covers kernel acquire > with IKE state #93 and IPsec state #0 - due to duplicate acquire? > Jan 22 12:43:06 sol pluto[24350]: existing bare shunt found - refusing > to add a duplicate Jan 22 12:43:06 sol pluto[24350]: ignoring found existing > connection instance "tunnel8"[10] 95.61.168.133 that covers kernel acquire > with IKE state #93 and IPsec state #0 - due to duplicate acquire? > Jan 22 12:43:36 sol pluto[24350]: existing bare shunt found - refusing > to add a duplicate Jan 22 12:43:36 sol pluto[24350]: ignoring found existing > connection instance "tunnel8"[10] 95.61.168.133 that covers kernel acquire > with IKE state #93 and IPsec state #0 - due to duplicate acquire? > Jan 22 12:44:06 sol pluto[24350]: existing bare shunt found - refusing > to add a duplicate Jan 22 12:44:06 sol pluto[24350]: ignoring found existing > connection instance "tunnel8"[10] 95.61.168.133 that covers kernel acquire > with IKE state #93 and IPsec state #0 - due to duplicate acquire? > Jan 22 12:44:37 sol pluto[24350]: existing bare shunt found - refusing > to add a duplicate Jan 22 12:44:37 sol pluto[24350]: ignoring found existing > connection instance "tunnel8"[10] 95.61.168.133 that covers kernel acquire > with IKE state #93 and IPsec state #0 - due to duplicate acquire? > Jan 22 12:45:07 sol pluto[24350]: existing bare shunt found - refusing > to add a duplicate Jan 22 12:45:07 sol pluto[24350]: ignoring found existing > connection instance "tunnel8"[10] 95.61.168.133 that covers kernel acquire > with IKE state #93 and IPsec state #0 - due to duplicate acquire? > Jan 22 12:45:12 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #93: > received Delete SA payload: self-deleting ISAKMP State #93 > > > > > My configuration: > conn tunnel8-aggr > aggrmode=yes > also=tunnel8 > > conn tunnel8 > pfs=no > type=tunnel > auto=add > ikev2=no > phase2=esp > authby=secret > keyingtries=3 > ikelifetime=24h > salifetime=1h > left=92.211.123.17 > leftsubnet=0.0.0.0/0 > [email protected] <mailto:[email protected]> > right=%any > rightid=%any > rightaddresspool=192.168.20.100-192.168.20.254 > dpddelay=30 > dpdtimeout=300 > dpdaction=clear > leftxauthserver=yes > rightxauthclient=yes > leftmodecfgserver=yes > rightmodecfgclient=yes > modecfgpull=yes > fragmentation=yes > xauthby=file > > > > > > > -- > Saludos / Regards / Cumprimentos > Ant?nio Silva > > > > >> On 21 Jan 2021, at 20:01, Michael Schwartzkopff <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 21.01.21 20:53, Kontakt wrote: >>> Hello, >>> I have a problem. ipsec tunnel compiled on libreswan 4.1 (centos 8) >>> for 1 client causes it to disconnect after 3600s. the same >>> configuration on libreswan 3.23 (centos 7) does not cause such >>> problems. conf file, password, iptables, entries in routing table identical. >>> I checked sysctl - identical. the only difference is selinux (centos >>> 7 has enforce, centos 8 disabled). >>> >>> libreswan 3.23 (centos 7): >>> >>> *ipsec verify*Verifying installed system and configuration files >>> >>> Version check and ipsec on-path [OK] Libreswan 3.23 (netkey) on >>> 3.10.0-862.3.2.el7.x86_64 Checking for IPsec support in kernel [OK] >>> NETKEY: Testing XFRM related proc values >>> ICMP default / send_redirects [NOT DISABLED] >>> >>> Disable / proc / sys / net / ipv4 / conf / * / send_redirects or >>> NETKEY will act on or cause sending of bogus ICMP redirects! >>> >>> ICMP default / accept_redirects [OK] >>> XFRM larval drop [OK] >>> Pluto ipsec.conf syntax [OK] >>> Two or more interfaces found, checking IP forwarding [OK] Checking >>> rp_filter [ENABLED] / proc / sys / net / ipv4 / conf / all / >>> rp_filter [ENABLED] / proc / sys / net / ipv4 / conf / default / >>> rp_filter [ENABLED] / proc / sys / net / ipv4 / conf / em1 / >>> rp_filter [ENABLED] / proc / sys / net / ipv4 / conf / em2 / >>> rp_filter [ENABLED] / proc / sys / net / ipv4 / conf / ip_vti0 / >>> rp_filter [ENABLED] >>> rp_filter is not fully aware of IPsec and should be disabled >>> Checking that pluto is running [OK] Pluto listening for IKE on udp >>> 500 [OK] Pluto listening for IKE / NAT-T on udp 4500 [OK] Pluto >>> ipsec.secret syntax [OK] Checking 'ip' command [OK] Checking >>> 'iptables' command [OK] Checking 'prelink' command does not >>> interfere with FIPS [OK] Checking for obsolete ipsec.conf options >>> [OK] >>> >>> ipsec verify: encountered 12 errors - see 'man ipsec_verify' for >>> help >>> >>> *And for libreswan 4.1 (centos 8):* >>> * ipsec verify* >>> >>> Verifying installed system and configuration files >>> >>> Version check and ipsec on-path [OK] Libreswan 4.1 (netkey) on >>> 4.18.0-193.28.1.el8_2.x86_64 Checking for IPsec support in kernel >>> [OK] >>> NETKEY: Testing XFRM related proc values >>> ICMP default / send_redirects [OK] >>> ICMP default / accept_redirects [OK] >>> XFRM larval drop [OK] >>> Pluto ipsec.conf syntax [OK] >>> Checking rp_filter [OK] >>> Checking that pluto is running [OK] >>> Pluto listening for IKE on udp 500 [OK] Pluto listening for IKE / >>> NAT-T on udp 4500 [OK] Pluto ipsec.secret syntax [OK] Checking 'ip' >>> command [OK] Checking 'iptables' command [OK] Checking 'prelink' >>> command does not interfere with FIPS [OK] Checking for obsolete >>> ipsec.conf options [OK] >>> >>> Where to look for the problem? >>> >>> >>> >>> _______________________________________________ >>> Swan mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.libreswan.org/mailman/listinfo/swan >>> <https://lists.libreswan.org/mailman/listinfo/swan> >> >> >> Logs? of both sides? >> >> Seems the child negotiation somehow fails. But the reason should be in the >> logs. >> >> >> >> Mit freundlichen Gr??en, >> >> -- >> >> [*] sys4 AG >> >> https://sys4.de <https://sys4.de/>, +49 (89) 30 90 46 64 >> Schlei?heimer Stra?e 26/MG,80333 M?nchen >> >> Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 >> Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief >> Aufsichtsratsvorsitzender: Florian Kirstein >> _______________________________________________ >> Swan mailing list >> [email protected] <mailto:[email protected]> >> https://lists.libreswan.org/mailman/listinfo/swan > > _______________________________________________ > Swan mailing list > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.libreswan.org/pipermail/swan/attachments/20210122/2848a24a/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan ------------------------------ End of Swan Digest, Vol 97, Issue 17 ************************************ _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
