dennisstritzke / ipsec_exporter

Prometheus exporter for IPsec metrics.

IPsec Exporter

Prometheus exporter for ipsec metrics, written in Go.

Deprecation

PROJECT DEPRECATED: This project is no longer maintained and patched for security updates. Repository will be archived soon.

Use https://github.com/torilabs/ipsec-prometheus-exporter instead.

Functionality

The IPsec exporter is determining the state of the configured IPsec tunnels via the following procedure.

1. Starting up the ipsec.conf is read. All tunnels configured via the conn keyword are observed.
2. If the /metrics endpoint is queried, the exporter calls ipsec status <tunnel name> for each configured connection. The output is parsed.
   • If the output contains ESTABLISHED, we assume that only the connection is up.
   • If the output contains INSTALLED, we assume that the tunnel is up and running.
   • If the output contains no match, we assume that the connection is down.

Value Definition

Metric	Value	Description
ipsec_status	0	The connection is established and tunnel is installed. The tunnel is up and running.
ipsec_status	1	The connection is established, but the tunnel is not up.
ipsec_status	2	The tunnel is down.
ipsec_status	3	The tunnel is in an unknown state.
ipsec_status	4	The tunnel is ignored.

ipsec_exporter's Issues

Cannot retrieve Tunnel status from within docker container

Hi,
I am trying to deploy the ipsec-exporter as a docker container on a host that is running ipsec tunnels. I have mounted the following files and folders, to be able to execute ipsec commands from within the container:

volumes:
      - /etc/ipsec.conf:/etc/ipsec.conf:ro
      - /usr/sbin/ipsec:/usr/sbin/ipsec
      - /usr/lib/ipsec/:/usr/lib/ipsec/
      - /lib/x86_64-linux-gnu/libcap.so.2:/lib/x86_64-linux-gnu/libcap.so.2
      - /var/run/:/var/run/

Within the container, I can successfully execute ipsec status and receive this status

no files found matching '/etc/strongswan.conf'
Security Associations (2 up, 0 connecting):
     Tunnel1[33]: ESTABLISHED 2 hours ago, X.X.X.X[x.x.x.x]...Y.Y.Y.Y[y.y.y.y]
     Tunnel1{187}:  INSTALLED, TUNNEL, reqid 20, ESP in UDP SPIs: c89e5ea2_i c8e8577e_o
     Tunnel1{187}:   X.X.X.X/24 === Y.Y.Y.Y/16
   ...

However, when I access the /metrics endpoint of the container, I see
ipsec-exporter_1 | time="2022-06-27T14:03:34Z" level=warning msg="Unable to retrieve the status of tunnel 'Tunnel1'. Reason: exit status 1" source="status.go:66" in the logs.

I already disabled app-armor for usr.lib.ipsec.charon and usr.lib.ipsec.stroke but that didn't help. I am out of ideas and would appreciate any help :)

support centos based systems

On Centos there is no ipsec command. Instead you have to use strongswan like strongswan statusall

ipsec_exporter crashes now and then

From time to time ipsec_exporter crashed with this stacktrace:

May 09 15:08:42 vpnserver ipsec_exporter[32398]: fatal error: concurrent map read and map write
May 09 15:08:42 vpnserver ipsec_exporter[32398]: goroutine 25 [running]:
May 09 15:08:42 vpnserver ipsec_exporter[32398]: runtime.throw(0x837534, 0x21)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/runtime/panic.go:616 +0x81 fp=0xc420049b28 sp=0xc420049b08 pc=0x429151
May 09 15:08:42 vpnserver ipsec_exporter[32398]: runtime.mapaccess1_faststr(0x7b5420, 0xc42006b620, 0xc420117fda, 0x17, 0x0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/runtime/hashmap_fast.go:181 +0x421 fp=0xc420049b98 sp=0xc420049b28 pc=0x409f61
May 09 15:08:42 vpnserver ipsec_exporter[32398]: github.com/dennisstritzke/ipsec_exporter/ipsecexporter.IpSecStatus.PrometheusMetrics(0xc42006b620, 0xc42006b620, 0xc420022000)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /Users/STRITD/golang/src/github.com/dennisstritzke/ipsec_exporter/ipsecexporter/ipsec.go:59 +0x11f fp=0xc420049ca8 sp=0xc420049b98 pc=0x74d46f
May 09 15:08:42 vpnserver ipsec_exporter[32398]: github.com/dennisstritzke/ipsec_exporter/ipsecexporter.prometheusMetrics(0x87bfe0, 0xc4203ac000, 0xc42037c300)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /Users/STRITD/golang/src/github.com/dennisstritzke/ipsec_exporter/ipsecexporter/serve.go:40 +0x3b fp=0xc420049cf0 sp=0xc420049ca8 pc=0x74de7b
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net/http.HandlerFunc.ServeHTTP(0x847fa0, 0x87bfe0, 0xc4203ac000, 0xc42037c300)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:1947 +0x44 fp=0xc420049d18 sp=0xc420049cf0 pc=0x7255f4
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net/http.(*ServeMux).ServeHTTP(0xa8ac60, 0x87bfe0, 0xc4203ac000, 0xc42037c300)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:2337 +0x130 fp=0xc420049d58 sp=0xc420049d18 pc=0x727260
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net/http.serverHandler.ServeHTTP(0xc42006cb60, 0x87bfe0, 0xc4203ac000, 0xc42037c300)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:2694 +0xbc fp=0xc420049d88 sp=0xc420049d58 pc=0x72829c
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net/http.(*conn).serve(0xc4202a57c0, 0x87c460, 0xc42005a840)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:1830 +0x651 fp=0xc420049fc8 sp=0xc420049d88 pc=0x724611
May 09 15:08:42 vpnserver ipsec_exporter[32398]: runtime.goexit()
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/runtime/asm_amd64.s:2361 +0x1 fp=0xc420049fd0 sp=0xc420049fc8 pc=0x454c61
May 09 15:08:42 vpnserver ipsec_exporter[32398]: created by net/http.(*Server).Serve
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:2795 +0x27b
May 09 15:08:42 vpnserver ipsec_exporter[32398]: goroutine 1 [IO wait, 224 minutes]:
May 09 15:08:42 vpnserver ipsec_exporter[32398]: internal/poll.runtime_pollWait(0x7ff37d0bbf00, 0x72, 0x0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/runtime/netpoll.go:173 +0x57
May 09 15:08:42 vpnserver ipsec_exporter[32398]: internal/poll.(*pollDesc).wait(0xc42043c018, 0x72, 0xc42005a000, 0x0, 0x0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/internal/poll/fd_poll_runtime.go:85 +0x9b
May 09 15:08:42 vpnserver ipsec_exporter[32398]: internal/poll.(*pollDesc).waitRead(0xc42043c018, 0xffffffffffffff00, 0x0, 0x0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/internal/poll/fd_poll_runtime.go:90 +0x3d
May 09 15:08:42 vpnserver ipsec_exporter[32398]: internal/poll.(*FD).Accept(0xc42043c000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/internal/poll/fd_unix.go:372 +0x1a8
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net.(*netFD).accept(0xc42043c000, 0xc4200b6080, 0xc4201bfa70, 0x4021c8)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/fd_unix.go:238 +0x42
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net.(*TCPListener).accept(0xc42000c110, 0xc4201bfaa0, 0x401127, 0xc4200b6080)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/tcpsock_posix.go:136 +0x2e
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net.(*TCPListener).AcceptTCP(0xc42000c110, 0xc4201bfae8, 0xc4201bfaf0, 0x18)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/tcpsock.go:246 +0x49
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net/http.tcpKeepAliveListener.Accept(0xc42000c110, 0x848550, 0xc4200b6000, 0x87c520, 0xc42006ba70)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:3216 +0x2f
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net/http.(*Server).Serve(0xc42006cb60, 0x87c2e0, 0xc42000c110, 0x0, 0x0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:2770 +0x1a5
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net/http.(*Server).ListenAndServe(0xc42006cb60, 0xc42006cb60, 0x5)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:2711 +0xa9
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net/http.ListenAndServe(0xc42001e770, 0x5, 0x0, 0x0, 0x4, 0xc42001e770)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:2969 +0x7a
May 09 15:08:42 vpnserver ipsec_exporter[32398]: github.com/dennisstritzke/ipsec_exporter/ipsecexporter.Serve()
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /Users/STRITD/golang/src/github.com/dennisstritzke/ipsec_exporter/ipsecexporter/serve.go:29 +0x202
May 09 15:08:42 vpnserver ipsec_exporter[32398]: github.com/dennisstritzke/ipsec_exporter/cmd.defaultCommand(0xa857e0, 0xaa88d0, 0x0, 0x0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /Users/STRITD/golang/src/github.com/dennisstritzke/ipsec_exporter/cmd/root.go:40 +0x20
May 09 15:08:42 vpnserver ipsec_exporter[32398]: github.com/dennisstritzke/ipsec_exporter/vendor/github.com/spf13/cobra.(*Command).execute(0xa857e0, 0xc42001c1c0, 0x0, 0x0, 0xa857e0, 0xc42001c1c0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /Users/STRITD/golang/src/github.com/dennisstritzke/ipsec_exporter/vendor/github.com/spf13/cobra/command.go:760 +0x2c1
May 09 15:08:42 vpnserver ipsec_exporter[32398]: github.com/dennisstritzke/ipsec_exporter/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xa857e0, 0x23, 0xc420049f58, 0x74e127)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /Users/STRITD/golang/src/github.com/dennisstritzke/ipsec_exporter/vendor/github.com/spf13/cobra/command.go:846 +0x30a
May 09 15:08:42 vpnserver ipsec_exporter[32398]: github.com/dennisstritzke/ipsec_exporter/vendor/github.com/spf13/cobra.(*Command).Execute(0xa857e0, 0xc420068058, 0x0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /Users/STRITD/golang/src/github.com/dennisstritzke/ipsec_exporter/vendor/github.com/spf13/cobra/command.go:794 +0x2b
May 09 15:08:42 vpnserver ipsec_exporter[32398]: github.com/dennisstritzke/ipsec_exporter/cmd.Execute()
...skipping...
May 09 15:08:42 vpnserver ipsec_exporter[32398]: os/exec.(*Cmd).Output(0xc4200c4580, 0x5, 0xc4201b9bf8, 0x2, 0x2, 0xc4200c4580)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/os/exec/exec.go:500 +0xf5
May 09 15:08:42 vpnserver ipsec_exporter[32398]: github.com/dennisstritzke/ipsec_exporter/ipsecexporter.IpSecStatus.QueryStatus(0xc42006b620, 0xc420024570)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /Users/STRITD/golang/src/github.com/dennisstritzke/ipsec_exporter/ipsecexporter/ipsec.go:40 +0x122
May 09 15:08:42 vpnserver ipsec_exporter[32398]: github.com/dennisstritzke/ipsec_exporter/ipsecexporter.prometheusMetrics(0x87bfe0, 0xc4203ac0e0, 0xc420094600)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /Users/STRITD/golang/src/github.com/dennisstritzke/ipsec_exporter/ipsecexporter/serve.go:40 +0x2d
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net/http.HandlerFunc.ServeHTTP(0x847fa0, 0x87bfe0, 0xc4203ac0e0, 0xc420094600)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:1947 +0x44
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net/http.(*ServeMux).ServeHTTP(0xa8ac60, 0x87bfe0, 0xc4203ac0e0, 0xc420094600)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:2337 +0x130
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net/http.serverHandler.ServeHTTP(0xc42006cb60, 0x87bfe0, 0xc4203ac0e0, 0xc420094600)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:2694 +0xbc
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net/http.(*conn).serve(0xc4200b6000, 0x87c460, 0xc4202c8040)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:1830 +0x651
May 09 15:08:42 vpnserver ipsec_exporter[32398]: created by net/http.(*Server).Serve
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:2795 +0x27b
May 09 15:08:42 vpnserver ipsec_exporter[32398]: goroutine 52115 [runnable]:
May 09 15:08:42 vpnserver ipsec_exporter[32398]: os/exec.(*Cmd).Start.func1(0xc4200c4580, 0xc4203743a0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/os/exec/exec.go:395
May 09 15:08:42 vpnserver ipsec_exporter[32398]: created by os/exec.(*Cmd).Start
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/os/exec/exec.go:395 +0x5df
May 09 15:08:42 vpnserver ipsec_exporter[32398]: goroutine 52076 [IO wait]:
May 09 15:08:42 vpnserver systemd[1]: ipsec_exporter.service: Unit entered failed state.
May 09 15:08:42 vpnserver ipsec_exporter[32398]: internal/poll.runtime_pollWait(0x7ff37d0bbc90, 0x72, 0xc4204a4658)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/runtime/netpoll.go:173 +0x57
May 09 15:08:42 vpnserver ipsec_exporter[32398]: internal/poll.(*pollDesc).wait(0xc42043c098, 0x72, 0xffffffffffffff00, 0x878b00, 0xa513e0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/internal/poll/fd_poll_runtime.go:85 +0x9b
May 09 15:08:42 vpnserver ipsec_exporter[32398]: internal/poll.(*pollDesc).waitRead(0xc42043c098, 0xc42022e000, 0x1, 0x1)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/internal/poll/fd_poll_runtime.go:90 +0x3d
May 09 15:08:42 vpnserver ipsec_exporter[32398]: internal/poll.(*FD).Read(0xc42043c080, 0xc42022e0a1, 0x1, 0x1, 0x0, 0x0, 0x0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/internal/poll/fd_unix.go:157 +0x17d
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net.(*netFD).Read(0xc42043c080, 0xc42022e0a1, 0x1, 0x1, 0x59d0ff, 0xc42026c418, 0x0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/fd_unix.go:202 +0x4f
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net.(*conn).Read(0xc420230000, 0xc42022e0a1, 0x1, 0x1, 0x0, 0x0, 0x0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/net.go:176 +0x6a
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net/http.(*connReader).backgroundRead(0xc42022e090)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:668 +0x5a
May 09 15:08:42 vpnserver ipsec_exporter[32398]: created by net/http.(*connReader).startBackgroundRead
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:664 +0xce
May 09 15:08:42 vpnserver ipsec_exporter[32398]: goroutine 52038 [IO wait]:
May 09 15:08:42 vpnserver ipsec_exporter[32398]: internal/poll.runtime_pollWait(0x7ff37d0bbe30, 0x72, 0xc4203f4658)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/runtime/netpoll.go:173 +0x57
May 09 15:08:42 vpnserver ipsec_exporter[32398]: internal/poll.(*pollDesc).wait(0xc42043c218, 0x72, 0xffffffffffffff00, 0x878b00, 0xa513e0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/internal/poll/fd_poll_runtime.go:85 +0x9b
May 09 15:08:42 vpnserver ipsec_exporter[32398]: internal/poll.(*pollDesc).waitRead(0xc42043c218, 0xc420268200, 0x1, 0x1)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/internal/poll/fd_poll_runtime.go:90 +0x3d
May 09 15:08:42 vpnserver ipsec_exporter[32398]: internal/poll.(*FD).Read(0xc42043c200, 0xc420268221, 0x1, 0x1, 0x0, 0x0, 0x0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/internal/poll/fd_unix.go:157 +0x17d
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net.(*netFD).Read(0xc42043c200, 0xc420268221, 0x1, 0x1, 0x59d0ff, 0xc420390ef8, 0x0)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/fd_unix.go:202 +0x4f
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net.(*conn).Read(0xc42000c220, 0xc420268221, 0x1, 0x1, 0x0, 0x0, 0x0)
May 09 15:08:42 vpnserver systemd[1]: ipsec_exporter.service: Failed with result 'exit-code'.
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/net.go:176 +0x6a
May 09 15:08:42 vpnserver ipsec_exporter[32398]: net/http.(*connReader).backgroundRead(0xc420268210)
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:668 +0x5a
May 09 15:08:42 vpnserver ipsec_exporter[32398]: created by net/http.(*connReader).startBackgroundRead
May 09 15:08:42 vpnserver ipsec_exporter[32398]:         /usr/local/Cellar/go/1.10.1/libexec/src/net/http/server.go:664 +0xce

I don't know go. But as the word concurrent highlights multiple times, perhaps it has something to do with our setup. We are monitoring multiple VPN connections on the same server with ipsec_exporter. Perhaps that's the cause?

Network binding

Hello,

It would be great if we can had more flexibility when we want to bind ipsec exporter to a specific network address (IPv4 or IPv6 with a network port) and keep intact the previous generic behavior (only port).

I already committed a pull request:

#25

Default port is already allocated

Port 9101 is already used by HAProxy exporter

https://github.com/prometheus/prometheus/wiki/Default-port-allocations

https://prometheus.io/docs/instrumenting/writing_exporters/#port-numbers

It would be a small improvement to claim a free port and change the default to it :)

I suspect ipsec value of REKEYED results in non-zero status from ipsec_exporter

Thanks for a really useful tool! We've been using it for about a year.

We're intermittently getting alerts about tunnels being down when they're up and working.

I suspect ipsec value of REKEYED results in non-zero status from ipsec_exporter

$ ipsec status | grep expires
       aaa{56474}:  REKEYED, TUNNEL, reqid 2, expires in 110 seconds
  aaa-ilo{56476}:  REKEYED, TUNNEL, reqid 6, expires in 3 minutes

ipsec_exporter/ipsec/status.go

Lines 82 to 83 in 9f6164f

	tunnelEstablishedRegex := regexp.MustCompile(`{[0-9]+}: *INSTALLED`)
	connectionEstablishedRegex := regexp.MustCompile(`[[0-9]+]: *ESTABLISHED`)

Announce the exporter

If the exporter hits version 1.0 announce it according to the description in Writing exporters.

Support "Swan" based IPSec config

If user use "Swan"(libSwan/StrongSwan) based IPSec toolkits, There will be no configure info in ipsec.conf file.

Have any chance to add a config file for this exporter, let user can spec the connection name?

Align Exporter with 'Writing exporters' doc

The Writing exporters guide lists many things that aren't implemented within this exporter. Create issues for all of them.

Implement HTML landing page

The Writing exporters states that:

t’s nicer for users if visiting http://yourexporter/ has a simple HTML page with the name of the exporter, and a link to the /metrics page.

Implement that instead of the currently implemented redirect.

do not require to restart the exporter when a tunnel is added/removed

Hello,

currently having this setup:
Ubuntu 18.04.3 LTS (Bionic Beaver)
Kernel 4.15.0-62-generic
strongswan 5.6.2-1ubuntu2.4
/etc/ipsec.conf has "include /etc/ipsec.d/tunnels/*.conf" configured and tunnel config file are stored like /etc/ipsec.d/tunnels/{tunnel_name}.conf.

The problem is when removing/adding a tunnel conf file to /etc/ipsec.d/tunnels/ it does not show up/disappear automatically from metrics. You need to restart the ipsec_exporter for the tunnel to show up/disapear.

Introduce new metrics

• ipsec_in_bytes
• ipsec_out_bytes
• ipsec_in_packets_total
• ipsec_out_packets_total
• ipsec_up to track failed scrapes according to Writing exporters
  - [ ] ipsec_uptime_seconds time since tunnel was established

React on HUP signal

Reload the ipsec configuration, if a HUP signal is sent. Document the feature.

Create release automation on Git tag

Automatically create and upload a new ipsec_exporter release, if a Git tag is pushed.

Is this a permission issue?

I am getting this error when calling /metrics.

WARN[0093] Unable to retrieve the status of tunnel 'fw1'. Reason: exit status 1  source="status.go:60"
WARN[0093] Unable to retrieve the status of tunnel 'fw2'. Reason: exit status 1  source="status.go:60"

Update exporter to provide count number of connections for each security association

Depending on how you configure your IPSEC server, you can have multiple security associations that allow multiple number of connections per security association. You access this data on the command line by typing "ipsec status" or "ipsec statusall" on most major linux platforms such as Ubuntu LTS or CentOS. When you type in that command you will get the output similar to below. The exporter would return the number of "up" security associations that can be queried by prometheus.

Example1:
Security Associations (1 up, 0 connecting):

Example 2:
Security Associations (35 up, 0 connecting):

Unable to retrieve the status of tunnel

I'm getting the following error while trying to retrieve the metrics,

ipsec_exporter[2473115]: time="2022-10-20T09:30:30Z" level=warning msg="Unable to retrieve the status of tunnel 'Tunnel1'. Reason: exit status 1" source="status.go:66"

Add Version Command

Add a version subcommand to the ipsec exporter that displays the version and Git commit hash.

Evaluate VICI as data source

Currently, the ipsec_exporter uses the output of the ipsec statusall command. This was a quick and easy way to get the exporter working.

As far as I understand the ipsec command uses the VICI protocol to communicate with the daemon. If this is true this could

• make the data collection and general exporter architecture much cleaner, stable and easier to extend
• allow us to run the exporter as an unprivileged user without sudo (making #27 obsolete by the cleaner data collection approach)
• allow us to run the exporter in a Docker Container (effectively making #24 possible)
• this might also address issues like #16 & #17
• this might make issues like #29 & #32 much more straight forward to implement (as we would not rely on parsing cmd output anymore)

Feature request: Retrieve metrics for multiple SA's for the same conn

Hello,

I'm reaching you to check if it's possible to add the functionality to read multiple SA'a on the same tunnel/conn.

We have a usage case where a strongswan server is used as a vpn concentrator for EAP or XAUTH radius authenticated users.

A conn working in this mode can be detected by reading the "rightauth" or rightauth2" parameter in conn configuration file.

For this cases, we would need an additional parameter, that is the username, and then bytes and packets and IP for each user.

The output of "ipsec statusall conn" for this cases is like this:

Status of IKE charon daemon (strongSwan 5.6.2, Linux 4.15.0-91-generic, x86_64):
uptime: 2 days, since Jul 20 07:48:59 2020
malloc: sbrk 4956160, mmap 532480, used 3906288, free 1049872
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 7
loaded plugins: charon test-vectors unbound ldap pkcs11 tpm aesni aes rc2 sha2 sha1 md4 md5 mgf1 rdrand random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey dnscert ipseckey pem openssl gcrypt af-alg fips-prf gmp curve25519 agent chapoly xcbc cmac hmac ctr ccm gcm ntru bliss curl soup mysql sqlite attr kernel-netlink resolve socket-default connmark farp stroke updown eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap xauth-pam xauth-noauth tnc-tnccs tnccs-20 tnccs-11 tnccs-dynamic dhcp whitelist lookip error-notify certexpire led radattr addrblock unity counters
Listening IP addresses:
10.2.3.4
1.2.3.4
Connections:
conn1: 1.2.3.4...%any IKEv2, dpddelay=30s
conn1: local: [vpn.server.test] uses public key authentication
conn1: cert: "CN=vpn.server.test"
conn1: remote: uses EAP_RADIUS authentication with EAP identity '%any'
conn1: child: 0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
Security Associations (6 up, 0 connecting):
conn1[195]: ESTABLISHED 75 seconds ago, 1.2.3.4[vpn.server.test]...x.y.z.w[vpn.server.test]
conn1[195]: Remote EAP identity: user1
conn1[195]: IKEv2 SPIs: 7794f527b95240ae_i 405cc25b8b125520_r*, rekeying disabled
conn1[195]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
conn1{189}: INSTALLED, TUNNEL, reqid 64, ESP in UDP SPIs: cf925e2c_i 0ebaa365_o
conn1{189}: AES_CBC_256/HMAC_SHA2_256_128, 27978 bytes_i (115 pkts, 7s ago), 24888 bytes_o (93 pkts, 7s ago), rekeying disabled
conn1{189}: 0.0.0.0/0 === 192.168.1.5/32
conn1[189]: ESTABLISHED 34 minutes ago, 1.2.3.4[vpn.server.test]...x.y.z.w[vpn.server.test]
conn1[189]: Remote EAP identity: user2
conn1[189]: IKEv2 SPIs: b8f50ab49dbcb705_i 37d1d4c97fee3f1e_r*, rekeying disabled
conn1[189]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
conn1{183}: INSTALLED, TUNNEL, reqid 66, ESP in UDP SPIs: c9b2266b_i 0b136eed_o
conn1{183}: AES_CBC_256/HMAC_SHA2_256_128, 4967950 bytes_i (63894 pkts, 0s ago), 263756393 bytes_o (212175 pkts, 0s ago), rekeying disabled
conn1{183}: 0.0.0.0/0 === 192.168.1.57/32

The username can be retrieved from this line:

conn1[195]: Remote EAP identity: user1

And IP address from this:

conn1{189}: 0.0.0.0/0 === 192.168.1.5/32

Packets and bytes is the same as you already do.

The goal would be to have this metrics retrieved for every user connected in the result page.

like this for example:

ipsec_out_packets{tunnel="conn1",user="user1"} 12345

@dennisstritzke Do you think you can add this functionality ?

Thanks.

Introduce Changelog

Issue #5 introduced a breaking change. Create a changelog in accordance to Keep a Changelog to document relevant changes.

Follow common pattern for naming exporters

Hi! Thanks for your work with the ipsec exporter

Have few cosmetic suggestions, that might ease life for deployments:

1. remove "v" from the release version
   We use ansible to deploy exporters to our hosts, and all of the exporters we use follow common naming pattern except ipsec-exporter

In ansible role we use following variables to build URL and filename

prometheus_exporter_release_name: "{{prometheus_exporter_name}}-{{ prometheus_exporter_version }}.{{prometheus_exporter_arch }}"
url: "https://{{prometheus_website_name}}/{{prometheus_github_username}}/{{prometheus_exporter_name}}/releases/download/v{{ prometheus_exporter_version }}/{{ prometheus_exporter_release_name }}.tar.gz"

You can note "v" is used only in URL after releases/download/ but not in file name. And, as said before, this breaks this pattern for ipsec_exporter. You've introduced this in version 0.3.

2. Pack binary into directory with release name.
   Currently .tar.gz archive from Release page, after unpacking contains binary with full release name. As other exporters follow pattern of naming directory with full release name and putting binary with just exporter name inside:
   e.g.
   node_exporter has following structure:
   node_exporter-0.18.1.linux-amd64/node_exporter
node_exporter-0.17.0.linux-amd64/node_exporter

So for ipsec_exporter we have to hack our standard deployment process to bypass those small things with naming, that is working for other exporters.

Hope these are not a big changes and are not breaking things for you and other users.

ignore commented lines

The config loader logic isn't aware of commented lines and seems to pick them up anyway - I think this shouldn't happen.

I think they could easily be dropped here

ipsec_exporter/ipsec/configuration.go

Line 111 in 237214f

func (l *ipSecConfigurationLoader) extractLines(ipsecConfig string) []string {

Let me know if you agree and I'll gladly supply a PR

Tunnel configured as "auto=ignore" are reported as "down"

Hi Dennis,

we have a VPN gateway that has at least one tunnel with the configuration parameter "auto=ignore". Which causes the ipsec damon to do exactly this - ignore this tunnel configuration. The ipsec-exporter obviously does not distinguish between tunnels that are down because of an error and tunnels that are in the config, but have been configured as down administratively (by setting auto=ignore). As the ipsec daemon actually does not load those tunnel configurations, it should be okay to do the same on the ipsec-exporter.

tunnel up but the exporter show ipsec_status 2

Hello,

i run ipsec_exporter on a vyatta firewall (debian based), the metrics shows that all the tunnels are down status 2 when they are up and running.

ipsec_status{tunnel="peer-115"} 2
ipsec_status{tunnel="peer-138"} 2
ipsec_status{tunnel="peer-195"} 2
ipsec_status{tunnel="peer-198"} 2
ipsec_status{tunnel="peer-51"} 2
ipsec_status{tunnel="peer-83"} 2

peer-138.xx.xx.xx-tunnel-0{8987}: INSTALLED, TUNNEL, reqid 9, ESP SPIs: cef086aa_i c500ce25_o

and i am using /etc/ipsec.conf of couse with all the tunnel names which are properly reported in the metrics

and so on..

i downloaded the 0.3 version of the exporter and i am using this version of ipsec: Linux strongSwan U5.3.5/K4.4.95-amd64-vyos

any idea? thanks

Move to prometheus/client_golang

Move the implementation to use prometheus/client_golang. The home grown approach was useful to get started quickly. To implement feature like #6 cleanly a collector based approach will be much cleaner and readable.

• Define metric description for ipsec_status
• Implement collector that collects the metric for a specified config file
• Register one collector per config file on exporter startup

support to read /etc/ipsec.d/*.conf

Hi @dennisstritzke ,
Is there a way to configure support to read /etc/ipsec.d/*.conf ? instead of /etc/ipsec.conf ?

Thanks in advance,

Support libreswan

On centos system libreswan is used as default instead strongswan.

While the configuration syntax of the ipsec.conf is still the same the output is different. There is no ipsec statusall command instead there just ipsec status or other commands like ipsec trafficstatus

ipsec trafficstatus
006 #6: "<Connection-Name>", type=ESP, add_time=1554666951, inBytes=659216, outBytes=17850, id='<ID>'
006 #4: "<Connection-Name>", type=ESP, add_time=1554666819, inBytes=2628777, outBytes=49400, id='<ID>'