swanctl --list-something --json please? about strongswan

[harridu]

Actually I don't want to replace swanctl by my own tool. swanctl is already made for monitoring. Supporting json would make it more useful.

[harridu]

Please check the man page:

NAME
       swanctl - strongSwan configuration, control and monitoring command line interface.

[Thermi]

You can just use the python egg or ruby gem to communicate programmatically over VICI socket.

[Thermi]

No, swanctl is not made for monitoring. It's just a configuration tool. It's --raw and --pretty modes are just for printing all the information in a "good" format. It's not made for text scraping or anything else other than usage by a human.

[feckert]

Is there any news on this topic?
I would also like to query IPsec status information that is readable by the machine.

@Thermi As you know I work with OpenWrt and would like to add a status page to LuCI for strongswan.

Why is the output not in json?
Is there any parser for the output swanctl --list-sas --pretty
Is the output from swanctl --list-sas --pretty a common valid format as JSON?

[tobiasbrunner]

I would also like to query IPsec status information that is readable by the machine.

Then use the machine-readable VICI interface directly via one of the available bindings. The output of swanctl is intended for humans (--raw is for development/debugging and used for the simple grep checks in our regression tests, --pretty makes it more readable).

Is there any parser for the output swanctl --list-sas --pretty
Is the output from swanctl --list-sas --pretty a common valid format as JSON?

While it does look similar to JSON, it's just a simple text representation of the VICI messages (with {} used for sections and [] for lists and = to separate key-value pairs). It's not intended to be parsed again (the output is ambiguous, although the --pretty version could possibly be parsed as each key-value pair and list item is on a separate line).

[FlorianHeigl]

The bindings are suboptimal for a pure monitoring purpose.
I think originally this was understood, as per the mention in the man page that monitoring should be a job of swanctl.
and it's also normal - the class of tool (ctl) should be stable enough to use.

But the main thing is to have something. One thing is that the main tooling does not directly rely on those other languages and so the daemon might work fine yet no python (the only one i can talk about) would be installed. Especially if you think appliances, like pfSense etc. (besides from good FreeSWAN intro at CCC camp in 1999 thats my only touch point), where you utterly need to have monitoring. And it should not break on upgrades due to missing dependencies etc.

A clean route would be to have a SNMP MIB extension and subagent, so the perl route in theory. In practice, that is, idk, 50-100 times the effort of making a monitoring plugin that can screenscrape something. So even for the non-monitoring case of pure debugging, the current state is endagering the vpn admin while they're debugging. I suppose Linux people can solve this by plugin into something that has external connection handling, i.e. NetworkManager)

So the question is what's achievable.
a more stable output from swanctl would be ideal as it would help multiple use cases including manually monitoring the status. (Good output is a good human factors thing, debugging with bad output is a bad thing.

If I try to make a more actionable interpretation of what you wrote, the best option would be to develop / contribute a C based tool (swanmon) that would use the vici interface/socket and parses / provides output.

A person debugging would need to run it in a second session and could get quasi-live status updates.
A person building monitoring without relying on external libraries could run it. The output could be built to work well with i.e. TextFSM to reach a stable interface that is easy to use for screensrapers, and it could output JSON or other things alternatively.
If there's a read-only set of API calls in the bindings, there might even be an option to make use of that to gain a non-privileged monitor.

The bad thing is that VPN connections usually are fatally important, so any frontend would need to be well-designed.
So that means whatever a frontend relies on, it should be built by a seasoned person with good enough understanding of the IPsec state machines to ensure good reporting.
At that point we're leaving territory that is 'actionable'.

What seems possible, at the moment, within reach of less professional contributors:

• with help, identify the right source code that will generate the output
• build a json frontend with DTD'ed output
• build a mock swanmon that creates this output or human-readable one
• create parser templates that can be updated / versioned
• remove all stupid parsing layers once someone with necessary skills can build it in C

That would bring

• stable output
• implement tricky things as contributions or however someone skilled enough becomes available
• clearly handle output changes from swanctl and cleanly refuse to process them
• updating the template could re-enable processing

footnote:
maybe it's too much crazy, but there's not much else one can do. I have a sunday night and after that i'll have built this monitoring for the firewalls, for now.
I've used textfsm like once, so it's far too advanced to use here, and i'll just skip over any good practice and get the job done.
this means, i'm just burning time, and I would like to help "you" get to where there's a fund-it link where I can drop pay for a man-hour or two. and a few more people can do the same till it's enough for someone competent to solve it for real.
I only found out about this whole thing because there's so many broken / messed up / overengineered monitoring implementations for strongswan. I think I found 4-5. 1/5 even uses the vici interface.
but, you know, if they worked well / easily, i wouldn't even be here.

[feckert]

@FlorianHeigl Thank you for your detailed explanation.

We have not been idle and have written a small tool that outputs the data as they are as json via the VICI socket. The small tools uses the davici library.

That would be just the beginning. We still need to understand more about how IPsec works.