[Swan-commit] Changes to ref refs/heads/main
New commits:
commit 79ee4b3d6e73c065a1914344a8d76a3947d67200
Author: Andrew Cagney
Date: Fri May 14 15:27:57 2021 -0400
logging: eliminate lswlog_to_{error,debug}_stream()
Add and use failsafe_logger, when all else fails.
Note: this drops the code trying to send passert()/pexpect()
messages to whack. It could only work when executing the
whack event handler (for instance when executing a show command).
commit 5aca3967a7ca25107996bab75c6d764c8c1ae648
Author: Andrew Cagney
Date: Fri May 14 14:06:10 2021 -0400
addresspool: use llog_pexpect_fail()
commit 6058e6242173dea4abb5c2f3d4043fa81d63ac62
Author: Andrew Cagney
Date: Fri May 14 13:41:34 2021 -0400
logging: pass logger into log_whacks()
___
Swan-commit mailing list
Swan-commit@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 1d4ab289c438d272a5198ebaa1df90b1f390200c Author: Andrew Cagney Date: Fri May 14 20:35:10 2021 -0400 ikev2: switch responder to child after ikev2_child_sa_respond() ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit d977089ec0aa58dc14e26d89456dd5c12e3b2832 Author: Andrew Cagney Date: Fri May 14 18:59:01 2021 -0400 ikev2: move IKE_SA_established call out of ikev2_child_sa_respond() ... and only call when establishing the IKE SA's first child. commit cc847d3d2c18a682b234609317e592b84534ed54 Author: Andrew Cagney Date: Fri May 14 16:37:06 2021 -0400 ikev1: clone IKE_SA_established(), creating ISAKMP_established() ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits:
commit 2bcbadc0b415fedbe69428496ba97caf2fc96266
Author: Andrew Cagney
Date: Fri May 14 16:24:07 2021 -0400
server: fix printf("%s", NULL) from enum_name() call
Follow-up: server: update helper pool logs
___
Swan-commit mailing list
Swan-commit@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 72dcc4d87e7de3a89714951b8b49f2a7e923b378 Author: Andrew Cagney Date: Fri May 14 15:48:53 2021 -0400 connection: s/newest_isakmp_sa/newest_ike_sa/ ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit f408c3bdb76376f1a3991a042dc1aca7580ce9f3 Author: Andrew Cagney Date: Thu May 13 10:31:01 2021 -0400 connections: in release_connection(), don't expect CK_INSTANCE Caller's problem. ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 0c0fb5de16fe7894b3d4afb34fcc00557e3ff72c Author: Andrew Cagney Date: Fri May 14 13:31:18 2021 -0400 logging: delete log_pexpect.c; duplicate of pexpect.c ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit ef682eae2cfc2e77f8b0bf5c036427bbb5c807a2 Author: Andrew Cagney Date: Fri May 14 13:15:54 2021 -0400 server: update helper pool logs ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit ec340f440ce58cad656df25e255ec610b2f70580 Author: Andrew Cagney Date: Fri May 14 11:19:21 2021 -0400 ikev2: in respoder, move IKE_AUTH state switch to after processing CHILD's SA payload commit 272a9c923a925058750e8269c8db7f96524be244 Author: Andrew Cagney Date: Fri May 14 09:30:37 2021 -0400 ikev2: update ikev2_process_child_sa_payload() - rename to ikev2_process_childs_sa_payload() - make <> an explicit parameter - move to ikev2_child.[hc] ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 1e569d9cb876222bcd85c922d9ae56ae219646c2 Author: Andrew Cagney Date: Fri May 14 10:26:36 2021 -0400 testing: add refcnt.awk to post-mortem.sh Still experimental so ignore result. (otoh, when leak detective fails this may help) ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 892d5997740112d05d5fba24256824f696106bb9 Author: Kavinda Wewegama Date: Wed May 12 13:21:34 2021 -0500 pluto: unshare policy labels in connection `end`s * Prior to this fix, `pluto` would trigger a double free error when cleaning up `connection`s. Signed-off-by: Paul Wouters ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
Re: [Swan] SA lifetime too short, less than configured
On Fri, 14 May 2021, Ivan Kuznetsov wrote:
No, config lines are not ignored. Here is status output, it shows 'ike_life:
86400s' and 'ipsec_life: 28800s' implemented
[root@vpn3 ipsec.d]# ipsec auto --status | grep bkp/0x2
000 "bkp/0x2":
000 "bkp/0x2": ike_life: 86400s; ipsec_life: 28800s; replay_window: 32;
rekey_margin: 300s; rekey_fuzz: 100%; keyingtries: 3;
Can you show me: ipsec status |grep ike_life:
I'd like to see the other bkp/ connections to see if they are all
properly set to the same lifetimes (They should be because it is
instantiated from your subnetS= but lets check)
May 14 09:09:45.873173: "bkp/0x2" #94268: STATE_V2_IPSEC_I: IPsec SA
established tunnel mode {ESP=>0x2c052ce7 <0xa8985bfa
xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=none DPD=passive}
May 14 10:17:15.373003: "bkp/0x2" #94268: deleting other state #94268
(STATE_CHILDSA_DEL) aged 4049.567s and NOT sending notification
Just over one hour is really weird. Can you run with plutodebug=all,tmi
and show the log lines you see between these two messages?
Paul
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] SA lifetime too short, less than configured
Hi Paul
No, config lines are not ignored. Here is status output, it shows
'ike_life: 86400s' and 'ipsec_life: 28800s' implemented
[root@vpn3 ipsec.d]# ipsec auto --status | grep bkp/0x2
000 "bkp/0x2":
172.16.80.0/20===11.22.33.44<11.22.33.44>...55.66.77.88<55.66.77.88>===10.1.102.0/24;
erouted; eroute owner: #94673
000 "bkp/0x2": oriented; my_ip=unset; their_ip=unset;
my_updown=ipsec _updown;
000 "bkp/0x2": xauth us:none, xauth them:none, my_username=[any];
their_username=[any]
000 "bkp/0x2": our auth:secret, their auth:secret
000 "bkp/0x2": modecfg info: us:none, them:none, modecfg policy:push,
dns:unset, domains:unset, banner:unset, cat:unset;
000 "bkp/0x2": policy_label:unset;
000 "bkp/0x2": ike_life: 86400s; ipsec_life: 28800s; replay_window:
32; rekey_margin: 300s; rekey_fuzz: 100%; keyingtries: 3;
000 "bkp/0x2": retransmit-interval: 500ms; retransmit-timeout: 60s;
000 "bkp/0x2": initial-contact:yes; cisco-unity:no;
fake-strongswan:no; send-vendorid:no; send-no-esp-tfc:no;
000 "bkp/0x2": policy:
PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO;
000 "bkp/0x2": v2-auth-hash-policy: none;
000 "bkp/0x2": conn_prio: 20,24; interface: bond0.5; metric: 0; mtu:
unset; sa_prio:auto; sa_tfc:none;
000 "bkp/0x2": nflog-group: unset; mark: unset; vti-iface:unset;
vti-routing:no; vti-shared:no; nic-offload:auto;
000 "bkp/0x2": our idtype: ID_IPV4_ADDR; our id=11.22.33.44; their
idtype: ID_IPV4_ADDR; their id=55.66.77.88
000 "bkp/0x2": dpd: action:hold; delay:0; timeout:0; nat-t:
encaps:auto; nat_keepalive:yes; ikev1_natt:both
000 "bkp/0x2": newest ISAKMP SA: #94672; newest IPsec SA: #94673;
000 "bkp/0x2": aliases: bkp
000 "bkp/0x2": IKEv2 algorithm newest: AES_CBC_256-HMAC_SHA2_256-MODP2048
000 "bkp/0x2": ESP algorithm newest: AES_CBC_256-HMAC_SHA2_256_128;
pfsgroup=
000 #94672: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established);
EVENT_SA_REKEY in 79663s; newest ISAKMP; idle;
Here is log (grep'ed by 'bkp/0x2' too):
May 14 09:09:26.961678: added connection description "bkp/0x1"
May 14 09:09:26.961850: added connection description "bkp/0x2"
May 14 09:09:26.962022: added connection description "bkp/0x3"
May 14 09:09:26.962146: added connection description "bkp/0x4"
May 14 09:09:45.765182: "bkp/0x2" #94267: initiating IKEv2 IKE SA
May 14 09:09:45.765214: "bkp/0x2": local IKE proposals (IKE SA initiator
selecting KE):
May 14 09:09:45.765223: "bkp/0x2":
1:IKE=AES_GCM_C_256-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
May 14 09:09:45.765229: "bkp/0x2":
2:IKE=AES_GCM_C_128-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
May 14 09:09:45.765235: "bkp/0x2":
3:IKE=AES_CBC_256-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
May 14 09:09:45.765241: "bkp/0x2":
4:IKE=AES_CBC_128-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
May 14 09:09:45.766146: "bkp/0x2" #94267: STATE_PARENT_I1: sent v2I1,
expected v2R1
May 14 09:09:45.805238: "bkp/0x2" #94267: sending INITIAL_CONTACT
May 14 09:09:45.805354: "bkp/0x2": local ESP/AH proposals (IKE SA
initiator emitting ESP/AH proposals):
May 14 09:09:45.805365: "bkp/0x2": 1:ESP=AES_GCM_C_256-NONE-NONE-DISABLED
May 14 09:09:45.805370: "bkp/0x2": 2:ESP=AES_GCM_C_128-NONE-NONE-DISABLED
May 14 09:09:45.805375: "bkp/0x2":
3:ESP=AES_CBC_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-NONE-DISABLED
May 14 09:09:45.805380: "bkp/0x2":
4:ESP=AES_CBC_128-HMAC_SHA2_512_256+HMAC_SHA2_256_128-NONE-DISABLED
May 14 09:09:45.805415: "bkp/0x2" #94268: STATE_PARENT_I2: sent v2I2,
expected v2R2 {auth=IKEv2 cipher=AES_CBC_256 integ=HMAC_SHA2_256_128
prf=HMAC_SHA2_256 group=MODP2048}
May 14 09:09:45.842717: "bkp/0x2" #94268: IKEv2 mode peer ID is
ID_IPV4_ADDR: '55.66.77.88'
May 14 09:09:45.842836: "bkp/0x2" #94268: Authenticated using authby=secret
May 14 09:09:45.873138: "bkp/0x2" #94268: negotiated connection
[172.16.80.0-172.16.95.255:0-65535 0] -> [10.1.102.0-10.1.102.255:0-65535 0]
May 14 09:09:45.873173: "bkp/0x2" #94268: STATE_V2_IPSEC_I: IPsec SA
established tunnel mode {ESP=>0x2c052ce7 <0xa8985bfa
xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=none DPD=passive}
May 14 10:17:15.373003: "bkp/0x2" #94268: deleting other state #94268
(STATE_CHILDSA_DEL) aged 4049.567s and NOT sending notification
May 14 10:17:15.393644: "bkp/0x2" #94267: deleting state
(STATE_IKESA_DEL) aged 4049.628s and NOT sending notification
May 14 10:17:15.393727: "bkp/0x2" #94267: deleting IKE SA but connection
is supposed to remain up; schedule EVENT_REVIVE_CONNS
May 14 10:17:15.393939: "bkp/0x2": initiating connection which received
a Delete/Notify but must remain up per local policy
May 14 10:17:15.394011: "bkp/0x2" #94344: initiating
Re: [Swan] SA lifetime too short, less than configured
If you have those empty lines in your config, perhaps that is causing the lines to be ignored ? Otherwise, show us the logs from the rekey event? It should tell us why. Sent from my iPhone > On May 14, 2021, at 03:46, Ivan Kuznetsov wrote: > > Hello > > We use libreswan 3.32 under Linux and have a IPsec peer recently upgraded > their Cisco ASA. Tunnel was migrated to IKEv2. All works fine except the > libreswan side restarts ISAKMP too often, mostly after 1h. ESP is restarted > too. Settings for lifetime are 24h for phase 1 and 8h for phase 2 on both > sides. rekeymargin has default value (300s) > > Why libreswan drops ISAKMP SA regardless of explicit settings? > > Libreswan configuration: > > conn bkp >type=tunnel >auto=start >authby=secret >left=11.22.33.44 >leftsubnet=172.16.80.0/20 >right=55.66.77.88 > rightsubnets=10.1.208.0/28,10.1.102.0/24,10.1.100.22/32,10.1.104.0/29 > >ikev2=yes >ikelifetime=24h >initial-contact=yes > >phase2=esp >salifetime=8h > #BKP's Cisco ASA has stranges regarding DH groups on phase2 >pfs=no > >rekey=yes >rekeymargin=5m >keyingtries=3 > >fragmentation=yes > #BKP's Cisco ASA has nonstadard DPD > #dpddelay=30 > #dpdtimeout=120 > #dpdaction=restart > > > Libreswan log is attached > > -- > Regards, Ivan Kuznetsov > SOLVO ltd > > ___ > Swan mailing list > Swan@lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 9ad30ed18b861d9d3a118942c89d9ae82a08a43b Author: Andrew Cagney Date: Fri May 14 07:30:07 2021 -0400 demux: change struct pbs_in *pbs to struct payload_digest *pd Some notifies need content of the packet header. (An astute reader will also notice that .chain and .pd somewhat overlap) commit 9b0fc83bdeabb7355703b2b5beb00986f27324c3 Author: Andrew Cagney Date: Thu May 13 22:11:31 2021 -0400 ikev2: move ikev2_process_child_sa_payload() call to before code emitting CP ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan] SA lifetime too short, less than configured
Hello
We use libreswan 3.32 under Linux and have a IPsec peer recently
upgraded their Cisco ASA. Tunnel was migrated to IKEv2. All works fine
except the libreswan side restarts ISAKMP too often, mostly after 1h.
ESP is restarted too. Settings for lifetime are 24h for phase 1 and 8h
for phase 2 on both sides. rekeymargin has default value (300s)
Why libreswan drops ISAKMP SA regardless of explicit settings?
Libreswan configuration:
conn bkp
type=tunnel
auto=start
authby=secret
left=11.22.33.44
leftsubnet=172.16.80.0/20
right=55.66.77.88
rightsubnets=10.1.208.0/28,10.1.102.0/24,10.1.100.22/32,10.1.104.0/29
ikev2=yes
ikelifetime=24h
initial-contact=yes
phase2=esp
salifetime=8h
#BKP's Cisco ASA has stranges regarding DH groups on phase2
pfs=no
rekey=yes
rekeymargin=5m
keyingtries=3
fragmentation=yes
#BKP's Cisco ASA has nonstadard DPD
#dpddelay=30
#dpdtimeout=120
#dpdaction=restart
Libreswan log is attached
--
Regards, Ivan Kuznetsov
SOLVO ltd
May 13 16:15:12.957820: "bkp/0x2" #92837: deleting other state #92837 (STATE_CHILDSA_DEL) aged 5702.583s and NOT sending notification
May 13 16:15:12.967038: "bkp/0x2" #92836: deleting state (STATE_IKESA_DEL) aged 5702.633s and NOT sending notification
May 13 16:15:12.967090: "bkp/0x2" #92836: deleting IKE SA but connection is supposed to remain up; schedule EVENT_REVIVE_CONNS
May 13 16:15:12.967201: "bkp/0x2": initiating connection which received a Delete/Notify but must remain up per local policy
May 13 16:15:12.967238: "bkp/0x2" #92959: initiating IKEv2 IKE SA
May 13 16:15:12.968129: "bkp/0x2" #92959: STATE_PARENT_I1: sent v2I1, expected v2R1
May 13 16:15:13.007403: "bkp/0x2" #92959: sending INITIAL_CONTACT
May 13 16:15:13.007540: "bkp/0x2" #92960: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
May 13 16:15:13.044523: "bkp/0x2" #92960: IKEv2 mode peer ID is ID_IPV4_ADDR: '55.66.77.88'
May 13 16:15:13.044645: "bkp/0x2" #92960: Authenticated using authby=secret
May 13 16:15:13.053699: "bkp/0x2" #92960: negotiated connection [172.16.80.0-172.16.95.255:0-65535 0] -> [10.1.102.0-10.1.102.255:0-65535 0]
May 13 16:15:13.053719: "bkp/0x2" #92960: STATE_V2_IPSEC_I: IPsec SA established tunnel mode {ESP=>0x3ec67a0f <0x3514d4db xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=none DPD=passive}
May 13 16:46:59.518754: "bkp/0x2" #92960: deleting other state #92960 (STATE_CHILDSA_DEL) aged 1906.511s and NOT sending notification
May 13 16:46:59.526985: "bkp/0x2" #92959: deleting state (STATE_IKESA_DEL) aged 1906.559s and NOT sending notification
May 13 16:46:59.527026: "bkp/0x2" #92959: deleting IKE SA but connection is supposed to remain up; schedule EVENT_REVIVE_CONNS
May 13 16:46:59.527111: "bkp/0x2": initiating connection which received a Delete/Notify but must remain up per local policy
May 13 16:46:59.527144: "bkp/0x2" #93010: initiating IKEv2 IKE SA
May 13 16:46:59.528001: "bkp/0x2" #93010: STATE_PARENT_I1: sent v2I1, expected v2R1
May 13 16:46:59.567340: "bkp/0x2" #93010: sending INITIAL_CONTACT
May 13 16:46:59.567472: "bkp/0x2" #93011: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
May 13 16:46:59.604695: "bkp/0x2" #93011: IKEv2 mode peer ID is ID_IPV4_ADDR: '55.66.77.88'
May 13 16:46:59.604808: "bkp/0x2" #93011: Authenticated using authby=secret
May 13 16:46:59.613477: "bkp/0x2" #93011: negotiated connection [172.16.80.0-172.16.95.255:0-65535 0] -> [10.1.102.0-10.1.102.255:0-65535 0]
May 13 16:46:59.613507: "bkp/0x2" #93011: STATE_V2_IPSEC_I: IPsec SA established tunnel mode {ESP=>0xf765c4e7 <0x1fdac55e xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=none DPD=passive}
May 13 17:28:00.687384: "bkp/0x2" #93011: deleting other state #93011 (STATE_CHILDSA_DEL) aged 2461.120s and NOT sending notification
May 13 17:28:00.695676: "bkp/0x2" #93010: deleting state (STATE_IKESA_DEL) aged 2461.168s and NOT sending notification
May 13 17:28:00.695744: "bkp/0x2" #93010: deleting IKE SA but connection is supposed to remain up; schedule EVENT_REVIVE_CONNS
May 13 17:28:00.695887: "bkp/0x2": initiating connection which received a Delete/Notify but must remain up per local policy
May 13 17:28:00.695918: "bkp/0x2" #93056: initiating IKEv2 IKE SA
May 13 17:28:00.696736: "bkp/0x2" #93056: STATE_PARENT_I1: sent v2I1, expected v2R1
May 13 17:28:00.735876: "bkp/0x2" #93056: sending INITIAL_CONTACT
May 13 17:28:00.736020: "bkp/0x2" #93057: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
May 13 17:28:00.772933: "bkp/0x2" #93057: IKEv2 mode peer ID is ID_IPV4_ADDR: '55.66.77.88'
May 13 17:28:00.773033: "bkp/0x2" #93057: Authenticated using authby=secret
May 13
