Project

General

Profile

Bug #2746

swanctl parser

Added by Marco Berizzi almost 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Low
Category:
libcharon
Target version:
Start date:
Due date:
Estimated time:
Affected version:
5.6.3
Resolution:
Fixed

Description

Hello everyone,

I have found a little bug with the swanctl parser.

I have modified my swanctl.conf file from:

children {
ariston-networks-192_168_32_0 {
...
}
}

to:

children {
ariston-networks {
...
}
}

but after issuing:

swanctl -q
swanctl -r
swanctl -c

I always get:

swanctl -i -c ariston-networks
initiate failed: CHILD_SA config 'ariston-networks' not found

if I try with the old name, it is working:

swanctl -i -c ariston-networks-192_168_32_0
[IKE] establishing CHILD_SA ariston-networks-192_168_32_0{96837}
...

Associated revisions

Revision 40ed8124 (diff)
Added by Tobias Brunner almost 2 years ago

peer-cfg: Replace equal child configs with newly added ones

Otherwise, renamed child configs would still be known to the daemon
under their old name.

Fixes #2746.

History

#1 Updated by Tobias Brunner almost 2 years ago

  • Tracker changed from Bug to Issue
  • Status changed from New to Feedback
  • Start date deleted (05.09.2018)

I have found a little bug with the swanctl parser.

What bug? And why in the parser?

but after issuing:

swanctl -q
swanctl -r
swanctl -c

Why the last command? -q includes -c.

Anyway, read the daemon log during these commands to see what's going on (e.g. if child configs are actually updated etc.).

#2 Updated by Marco Berizzi almost 2 years ago

Hi Tobias,

I have found a little bug with the swanctl parser.

What bug? And why in the parser?

the bug or issue is that after running:

swanctl -q

the new (re)named <child> name is not recognized by
swanctl.

but after issuing:

swanctl -q
swanctl -r
swanctl -c

Why the last command? -q includes -c.

I did try to run all command options to see if any
of them were catching the change.

Anyway, read the daemon log during these commands to see what's going on

ok, tomorrow I will publish the logs.

(e.g. if child configs are actually updated etc.).

well, the children config wasn't changed. Only the <child>
name was changed.
Also ipsec statusall is showing the old <child> name.

Maybe swanctl is confused because none of the
parameters where changed in the children section,
so it will not update the <child> name.

#3 Updated by Marco Berizzi almost 2 years ago

Here is the charon.log when I run swanctl -q

Thu, 2018-09-06 09:51 09[CFG] vici client 74 requests: load-conn
Thu, 2018-09-06 09:51 09[CFG] conn ariston:
Thu, 2018-09-06 09:51 09[CFG] child ariston-networks:
Thu, 2018-09-06 09:51 09[CFG] rekey_time = 3600
Thu, 2018-09-06 09:51 09[CFG] life_time = 3960
Thu, 2018-09-06 09:51 09[CFG] rand_time = 360
Thu, 2018-09-06 09:51 09[CFG] rekey_bytes = 0
Thu, 2018-09-06 09:51 09[CFG] life_bytes = 0
Thu, 2018-09-06 09:51 09[CFG] rand_bytes = 0
Thu, 2018-09-06 09:51 09[CFG] rekey_packets = 0
Thu, 2018-09-06 09:51 09[CFG] life_packets = 0
Thu, 2018-09-06 09:51 09[CFG] rand_packets = 0
Thu, 2018-09-06 09:51 09[CFG] updown = (null)
Thu, 2018-09-06 09:51 09[CFG] hostaccess = 0
Thu, 2018-09-06 09:51 09[CFG] ipcomp = 0
Thu, 2018-09-06 09:51 09[CFG] mode = TUNNEL
Thu, 2018-09-06 09:51 09[CFG] policies = 1
Thu, 2018-09-06 09:51 09[CFG] policies_fwd_out = 0
Thu, 2018-09-06 09:51 09[CFG] dpd_action = clear
Thu, 2018-09-06 09:51 09[CFG] start_action = hold
Thu, 2018-09-06 09:51 09[CFG] close_action = clear
Thu, 2018-09-06 09:51 09[CFG] reqid = 0
Thu, 2018-09-06 09:51 09[CFG] tfc = 0
Thu, 2018-09-06 09:51 09[CFG] priority = 0
Thu, 2018-09-06 09:51 09[CFG] interface = (null)
Thu, 2018-09-06 09:51 09[CFG] mark_in = 0/0
Thu, 2018-09-06 09:51 09[CFG] mark_in_sa = 0
Thu, 2018-09-06 09:51 09[CFG] mark_out = 0/0
Thu, 2018-09-06 09:51 09[CFG] inactivity = 0
Thu, 2018-09-06 09:51 09[CFG] proposals = ESP:AES_CBC_256/HMAC_SHA2_512_256/ECP_521/NO_EXT_SEQ
Thu, 2018-09-06 09:51 09[CFG] local_ts = 10.2.2.0/30
Thu, 2018-09-06 09:51 09[CFG] remote_ts = 10.20.29.75/32 192.168.32.0/24
Thu, 2018-09-06 09:51 09[CFG] hw_offload = no
Thu, 2018-09-06 09:51 09[CFG] sha256_96 = 0
Thu, 2018-09-06 09:51 09[CFG] version = 2
Thu, 2018-09-06 09:51 09[CFG] local_addrs = 205.223.229.254
Thu, 2018-09-06 09:51 09[CFG] remote_addrs = 212.4.21.134
Thu, 2018-09-06 09:51 09[CFG] local_port = 500
Thu, 2018-09-06 09:51 09[CFG] remote_port = 500
Thu, 2018-09-06 09:51 09[CFG] send_certreq = 0
Thu, 2018-09-06 09:51 09[CFG] send_cert = CERT_NEVER_SEND
Thu, 2018-09-06 09:51 09[CFG] mobike = 0
Thu, 2018-09-06 09:51 09[CFG] aggressive = 0
Thu, 2018-09-06 09:51 09[CFG] dscp = 0x00
Thu, 2018-09-06 09:51 09[CFG] encap = 0
Thu, 2018-09-06 09:51 09[CFG] dpd_delay = 0
Thu, 2018-09-06 09:51 09[CFG] dpd_timeout = 0
Thu, 2018-09-06 09:51 09[CFG] fragmentation = 2
Thu, 2018-09-06 09:51 09[CFG] unique = UNIQUE_NO
Thu, 2018-09-06 09:51 09[CFG] keyingtries = 0
Thu, 2018-09-06 09:51 09[CFG] reauth_time = 86400
Thu, 2018-09-06 09:51 09[CFG] rekey_time = 0
Thu, 2018-09-06 09:51 09[CFG] over_time = 8640
Thu, 2018-09-06 09:51 09[CFG] rand_time = 8640
Thu, 2018-09-06 09:51 09[CFG] proposals = IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/ECP_521
Thu, 2018-09-06 09:51 09[CFG] local:
Thu, 2018-09-06 09:51 09[CFG] id = 205.223.229.254
Thu, 2018-09-06 09:51 09[CFG] class = pre-shared key
Thu, 2018-09-06 09:51 09[CFG] remote:
Thu, 2018-09-06 09:51 09[CFG] id = 212.4.21.134
Thu, 2018-09-06 09:51 09[CFG] class = pre-shared key
Thu, 2018-09-06 09:51 09[CFG] updated vici connection: ariston

the child name is correct (ariston-networks).

But swanctl -l show the old name (ariston-networks-192_168_32_0):

ariston-networks-192_168_32_0: #103698, reqid 364, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_512_256/ECP_521
installed 2109s ago, rekeying in 1237s, expires in 1852s
in c6fe1796, 0 bytes, 0 packets
out c8965931, 0 bytes, 0 packets
local 10.2.2.0/30
remote 10.20.29.75/32 192.168.32.0/24
ariston-networks-192_168_32_0: #103798, reqid 364, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_512_256/ECP_521
installed 1343s ago, rekeying in 1946s, expires in 2617s
in c85d2ef1, 0 bytes, 0 packets
out c8965932, 0 bytes, 0 packets
local 10.2.2.0/30
remote 10.20.29.75/32 192.168.32.0/24
ariston-networks-192_168_32_0: #103811, reqid 364, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_512_256/ECP_521
installed 1241s ago, rekeying in 2138s, expires in 2719s
in cdfe58fe, 61354 bytes, 71 packets, 1004s ago
out c8965933, 7480 bytes, 37 packets, 1004s ago
local 10.2.2.0/30
remote 10.20.29.75/32 192.168.32.0/24

and also ipsec statusall show the same old name:

ariston-networks-192_168_32_0: child: 10.2.2.0/30 === 10.20.29.75/32 192.168.32.0/24 TUNNEL
Routed Connections:
ariston-networks-192_168_32_0{96058}: ROUTED, TUNNEL, reqid 364
ariston-networks-192_168_32_0{96058}: 10.2.2.0/30 === 10.20.29.75/32 192.168.32.0/24

#4 Updated by Tobias Brunner almost 2 years ago

  • Tracker changed from Issue to Bug
  • Category changed from swanctl to libcharon
  • Target version set to 5.7.0

Thanks for the additional info.

I have found a little bug with the swanctl parser.

What bug? And why in the parser?

the bug or issue is that after running:

swanctl -q

the new (re)named <child> name is not recognized by
swanctl.

That has nothing to do with swanctl. The --initiate command just forwards the options to the daemon, it does not do any config parsing at all (which is why it's possible to initiate connections that are defined by other backends, e.g. in a database or even in ipsec.conf).

(e.g. if child configs are actually updated etc.).

well, the children config wasn't changed. Only the <child>
name was changed.
Also ipsec statusall is showing the old <child> name.

Maybe swanctl is confused because none of the
parameters where changed in the children section,
so it will not update the <child> name.

Again, has nothing to do with swanctl. But yes, the code that replaces child configs (source:src/libcharon/config/peer_cfg.c#L257) does not compare the name and keeps the existing config if nothing else changed. These are globally shared objects, so I'm not sure if changing that would have any adverse effects. But I pushed a patch that replaces equal configs with the new one to the 2746-replace-child-cfg branch.

#5 Updated by Marco Berizzi almost 2 years ago

Tobias Brunner wrote:

That has nothing to do with swanctl. The --initiate command just forwards the options to the daemon, it does not do any config parsing at all (which is why it's possible to initiate connections that are defined by other backends, e.g. in a database or even in ipsec.conf).

thanks for the explanation.

Again, has nothing to do with swanctl. But yes, the code that replaces child configs (source:src/libcharon/config/peer_cfg.c#L257) does not compare the name and keeps the existing config if nothing else changed. These are globally shared objects, so I'm not sure if changing that would have any adverse effects. But I pushed a patch that replaces equal configs with the new one to the 2746-replace-child-cfg branch.

thanks for fixing it. Apologies but I cannot test before next monday.

#6 Updated by Marco Berizzi almost 2 years ago

Hi Tobias,

grabbed&built strongswan-2746-replace-child-cfg

everything is working as expected:

root@Calimero:/tmp/STRONGSWAN/strongswan-2746-replace-child-cfg# swanctl -L
[...]
net-0ab10000_bubbone: TUNNEL, rekeying every 28800s
local: 10.139.10.0/23
remote: 10.177.0.0/16

root@Calimero:/tmp/STRONGSWAN/strongswan-2746-replace-child-cfg# swanctl -q
loaded ike secret 'ike'
no authorities found, 0 unloaded
no pools found, 0 unloaded
loaded connection 'generali'
successfully loaded 1 connections, 0 unloaded
root@Calimero:/tmp/STRONGSWAN/strongswan-2746-replace-child-cfg# swanctl -L
[...]
net-0ab10000: TUNNEL, rekeying every 28800s
local: 10.139.10.0/23
remote: 10.177.0.0/16

You may close this ticket.

Thanks for fixing this problem.

#7 Updated by Tobias Brunner almost 2 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Fixed

OK, great.

Also available in: Atom PDF