liquidat / nagios-icinga-openvpn Goto Github PK

Hi, while troubleshooting an issue today, I noticed this description for the --tls-auth-inverse flag:

  --tls-auth-inverse    set tls-auth file direction to inverse (1)

That suggests to me that passing --tls-auth-inverse to check_openvpn is analogous to setting tls-auth secret.key 1 in my openvpn.conf. However, I never even knew about this option, because things just work out of the box. Which is strange in hindsight, because my server uses tls-auth ... 0 and all of my clients use tls-auth ... 1!

Is the documentation backwards, or is something else happening?

This plugin return OK when checking the port of an HTTP server (in tcp mode), just because, regardless of the query, the HTTP server answers something. That would be nice if this plugin checked whether the data returned fitted the openvpn procol.
A possible use case is to monitor that sslh is working fine.

Hi all, I forgot to add a licence when I started this project. To be on the same side, I will add the MIT licence so this packages can also be added to Linux distributions, packages, etc.

Any objections?
@aptituz @andiwand @oh2kku @Hagfjall @alarig

Your script will output that, but exits with a 0 not a 2, so the server says ok.

I was able to get this to work when using the tls-auth option but is there a way to get it to work with the tls-crypt option?

Thanks for your work on this!

Packet verification fails for set-ups using other non-SHA1 hashes like SHA256 because, the length of the HMAC digest is hard-coded to 20 bytes (SHA1) in line 92.

Possible fix, change line 92 to:
elif len(packet) - struct.unpack('>B', packet[17+digest_size:18+digest_size])[0] * 4 == 30+digest_size: plen = 2 # type(1) sid(8) hmac(digest_size) pid(4) ts(4) mpida(1) rsid(8) mpid(mpida*4)

When I tail my /var/log/openvpn/int.log file, every two seconds it adds the following entry:
Thu Oct 15 08:07:24 2015 us=130000 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)

Is this happening on yours as well? Wasn't sure if there was a better work around to prevent this. The check currently happens every minute and it takes a full minute for the connection refused to stop so it essentially never ends.

Here is the full text (10.1.1.1 in this example would be my Nagios server):
Thu Oct 15 08:15:21 2015 us=396443 MULTI: multi_create_instance called
Thu Oct 15 08:15:21 2015 us=396513 10.1.1.1:54134 Re-using SSL/TLS context
Thu Oct 15 08:15:21 2015 us=396534 10.1.1.1:54134 LZO compression initialized
Thu Oct 15 08:15:21 2015 us=396601 10.1.1.1:54134 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Oct 15 08:15:21 2015 us=396613 10.1.1.1:54134 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Oct 15 08:15:21 2015 us=396642 10.1.1.1:54134 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Thu Oct 15 08:15:21 2015 us=396650 10.1.1.1:54134 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Thu Oct 15 08:15:21 2015 us=396665 10.1.1.1:54134 Local Options hash (VER=V4): '530fdded'
Thu Oct 15 08:15:21 2015 us=396676 10.1.1.1:54134 Expected Remote Options hash (VER=V4): '41690919'
Thu Oct 15 08:15:21 2015 us=396705 10.1.1.1:54134 TLS: Initial packet from 10.1.1.1:54134, sid=01000000 00000000
Thu Oct 15 08:15:21 2015 us=396715 10.1.1.1:54134 TLS Error: reading acknowledgement record from packet
Thu Oct 15 08:15:24 2015 us=199771 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Thu Oct 15 08:15:26 2015 us=609427 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Thu Oct 15 08:15:29 2015 us=200170 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)

I have tls-auth enabled on my ovpn server. I supply the required file (the TLS key from the server, which the script accepts and sends) but the command fails saying CRIT: Not responding.

Checking the ovpn logs I see that it was having trouble reading the tls key.

Tue Dec 18 21:23:01 2018 TCP connection established with [AF_INET]myip
Tue Dec 18 21:23:01 2018 myip TLS: Initial packet from [AF_INET]myip, sid=removed
Tue Dec 18 21:23:01 2018 myip tls-crypt unwrap error: packet too short
Tue Dec 18 21:23:01 2018 myip TLS Error: tls-crypt unwrapping failed from [AF_INET]myip
Tue Dec 18 21:23:01 2018 myip Fatal TLS error (check_tls_errors_co), restarting
Tue Dec 18 21:23:01 2018 myip SIGUSR1[soft,tls-error] received, client-instance restarting

Here us the command being run:

'/usr/lib/nagios/plugins/check_openvpn' '--tls-auth' '/usr/lib/nagios/plugins/ta.key' '-p' '1194' 'myip'

fix: https://github.com/andiwand/nagios-icinga-checks