[Swan] disconnect after 3600s

António Silva asilva at wirelessmundi.com
Fri Jan 22 14:21:16 UTC 2021


Hi,

It didn’t solve the issue.. It sill disconnect after an 1h.  Is there a new option we must set in version 4.1?

I’m change "salifetime=1h” to “salifetime=8h”, but this will delay the issue. 


--
Saludos / Regards / Cumprimentos
António Silva




> On 22 Jan 2021, at 12:06, António Silva <asilva at wirelessmundi.com> wrote:
> 
> 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 <asilva at wirelessmundi.com <mailto:asilva at wirelessmundi.com>> 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 'asilvapt at remote.local <mailto:asilvapt at remote.local>'
>> 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(asilvapt at remote.local <mailto:asilvapt at remote.local>:(null))
>> Jan 22 12:37:36 sol pluto[24350]: "tunnel8"[10] 95.61.168.133 #94: XAUTH: User asilvapt at remote.local <mailto:asilvapt at remote.local>: 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 XAUTHuser=asilvapt at remote.local <mailto:XAUTHuser=asilvapt at remote.local>
>> 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
>> 	leftid=@xauth.remote.local <mailto:leftid=@xauth.remote.local>
>> 	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 <ms at sys4.de <mailto:ms at sys4.de>> 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
>>>> Swan at lists.libreswan.org <mailto:Swan at lists.libreswan.org>
>>>> 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
>>> Swan at lists.libreswan.org <mailto:Swan at lists.libreswan.org>
>>> https://lists.libreswan.org/mailman/listinfo/swan <https://lists.libreswan.org/mailman/listinfo/swan>
>> 
>> _______________________________________________
>> Swan mailing list
>> Swan at lists.libreswan.org <mailto:Swan at lists.libreswan.org>
>> https://lists.libreswan.org/mailman/listinfo/swan
> 
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20210122/db4b211c/attachment-0001.html>


More information about the Swan mailing list