[Swan] Swan Digest, Vol 97, Issue 17

Fri Jan 22 13:39:01 UTC 2021

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 <swan-bounces at lists.libreswan.org> Im Auftrag von swan-request at lists.libreswan.org
Gesendet: Freitag, 22. Januar 2021 13:06
An: swan at lists.libreswan.org
Betreff: Swan Digest, Vol 97, Issue 17

Send Swan mailing list submissions to
	swan at lists.libreswan.org

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
	swan-request at lists.libreswan.org

You can reach the person managing the list at
	swan-owner at lists.libreswan.org

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 <asilva at wirelessmundi.com>
To: Michael Schwartzkopff <ms at sys4.de>
Cc: swan at lists.libreswan.org
Subject: Re: [Swan] disconnect after 3600s
Message-ID: <B057A2B8-742B-4A75-9139-54617EDAB560 at wirelessmundi.com>
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 <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
> 
> _______________________________________________
> 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/2848a24a/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Swan mailing list
Swan at lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

------------------------------

End of Swan Digest, Vol 97, Issue 17
************************************