A special Fortigate Check_MK plugin 2.3.1

Those of you who are suffered by the issue with duplicated service description, which is caused by a conflict of two different named checks: one built-in in Check_MK starting from 1.2.8 and one of mine.

This special version has other service descriptions and check names. The functionality is the same as in the version 2.3.

You can download the Check_MK package at the temporary place.

Update: After Robert had reported that the new version didn’t work under 1.2.8 and 1.4 versions of Check_MK, I have figured out that the plugin didn’t work (ran into an exception) because of a change between the versions 1.2.6 and 1.2.8 of Check_MK: the global variable nagios_state_names was renamed in core_state_names. Therefore I’ve created an updated version and am waiting for a confirmation, if this new version is working.

22 thoughts on “A special Fortigate Check_MK plugin 2.3.1

  1. Robert

    Hi Hermann
    Thx for the “Fix”.. but not work.

    UNKN | IPSec tunnel IKE_**** | [menu] | UNKNOWN – check failed – please submit a crash report! | 4 m 26.7 s
    “Update” mpk not work
    Reinstall, remove ftg & fortigate package an install again not helped….

    Thank you for your Help

    Reply
    1. Hermann Maurer Post author

      I’ve tested under Check_MK 1.2.6p16 successfully. Which version are you using?

      Reply
  2. Hermann Maurer Post author

    Robert, I guess I have got the reason and fixed the issue.
    The new version is here: http://hermannsspace.de/downloads/fgt-2.3.2.mkp
    Please remove the old ones (cmk -P remove fortigate; cmk -P remove fgt) and install this package by issuing cmk -P install fgt-2.3.2.mkp

    Please give me a short feedback, how it’s going.

    Reply
  3. m3rlinux

    Hi Hermann! Maybe I found another issue:
    I have a CRITICAL alert “FGT HA Status: CRIT – Not in Sync FGT60D…” on a Standalone system.
    Fortigate is: 60D
    Check_mk is: 1.2.8p18

    I installed the fgt-2.3.2.mkp package.

    If you need some more informations please ask.
    Thanks

    Reply
    1. m3rlinux

      Pardon! It isn’t due to your plugin but due the oid result:
      .1.3.6.1.4.1.12356.101.13.2.1.1.12.1 = INTEGER: 0
      .1.3.6.1.4.1.12356.101.13.2.1.1.15.1 = STRING: “00000000000000000000000000000000”

      There is something strange on Firewall configuration. I’ll investigate!
      Sorry again!

      Reply
  4. m3rlinux

    Hi again, I have another problem, I don’t understand if it could be due to plugin or due to wrong configuration.

    The Check_MK Discovery chashes for ZyWall (Firewalls), here the stack trace:

    File “/omd/sites/monitor/share/check_mk/modules/discovery.py”, line 260, in check_discovery
    ipaddress=ipaddress)

    File “/omd/sites/monitor/share/check_mk/modules/discovery.py”, line 865, in get_host_services
    return get_node_services(hostname, ipaddress, use_caches, do_snmp_scan, on_error)

    File “/omd/sites/monitor/share/check_mk/modules/discovery.py”, line 890, in get_node_services
    services = get_discovered_services(hostname, ipaddress, use_caches, do_snmp_scan, on_error)

    File “/omd/sites/monitor/share/check_mk/modules/discovery.py”, line 874, in get_discovered_services
    new_items = discover_services(hostname, None, use_caches, do_snmp_scan, on_error, ipaddress)

    File “/omd/sites/monitor/share/check_mk/modules/discovery.py”, line 602, in discover_services
    check_types = snmp_scan(hostname, ipaddress, on_error)

    File “/omd/sites/monitor/share/check_mk/modules/discovery.py”, line 704, in snmp_scan
    result = scan_function(oid_function)

    File “/omd/sites/monitor/local/share/check_mk/checks/fgt_sslvpn”, line 52, in
    “snmp_scan_function” : lambda oid: “2” in oid(“.1.3.6.1.4.1.12356.101.12.2.3.1.1.1”),

    Do you have any suggestions?

    Reply
    1. Hermann Maurer Post author

      what is the output of
      cmk –flush your_host_making_troubles
      cmk –debug -vII your_host_making_troubles

      Reply
  5. m3rlinux

    Sorry! Firs I had modified you check fgt_sslvpn, changing de line:
    “snmp_scan_function” : lambda oid: “2” in oid(“.1.3.6.1.4.1.12356.101.12.2.3.1.1.1”),
    with
    “snmp_scan_function” : lambda oid: oid(“.1.3.6.1.4.1.12356.101.12.2.3.1.1.1″),

    restoring your initial check the output is:

    Discovering services on 46.37.6.92:
    46.37.6.92:
    Running ‘snmpget -v2c -c ‘public’ -m ” -M ” -t 5.00 -r 2 -On -OQ -Oe -Ot 46.37.6.92 .1.3.6.1.2.1.1.1.0′
    SNMP answer: ==> [“ZyWALL 2 Plus”]
    Running ‘snmpget -v2c -c ‘public’ -m ” -M ” -t 5.00 -r 2 -On -OQ -Oe -Ot 46.37.6.92 .1.3.6.1.2.1.1.2.0′
    SNMP answer: ==> [.1.3.6.1.4.1.890.1.6]
    Running ‘snmpget -v2c -c ‘public’ -m ” -M ” -t 5.00 -r 2 -On -OQ -Oe -Ot 46.37.6.92 .1.3.6.1.4.1.231.2.10.2.1.1.0′
    SNMP answer: ==> [No Such Object available on this agent at this OID]
    Running ‘snmpget -v2c -c ‘public’ -m ” -M ” -t 5.00 -r 2 -On -OQ -Oe -Ot 46.37.6.92 .1.3.6.1.4.1.12356.101.14.2.4.0′
    SNMP answer: ==> [No Such Object available on this agent at this OID]
    Running ‘snmpget -v2c -c ‘public’ -m ” -M ” -t 5.00 -r 2 -On -OQ -Oe -Ot 46.37.6.92 .1.3.6.1.4.1.232.2.2.4.2.0′
    SNMP answer: ==> [No Such Object available on this agent at this OID]
    Running ‘snmpget -v2c -c ‘public’ -m ” -M ” -t 5.00 -r 2 -On -OQ -Oe -Ot 46.37.6.92 .1.3.6.1.2.1.43.11.1.1.6.1.1′
    SNMP answer: ==> [No Such Object available on this agent at this OID]
    Running ‘snmpget -v2c -c ‘public’ -m ” -M ” -t 5.00 -r 2 -On -OQ -Oe -Ot 46.37.6.92 .1.3.6.1.4.1.12356.101.12.2.3.1.1.1′
    SNMP answer: ==> [No Such Object available on this agent at this OID]
    Traceback (most recent call last):
    File “/omd/sites/monitor/share/check_mk/modules/check_mk.py”, line 5309, in
    do_discovery(hostnames, check_types, seen_I == 1)
    File “/omd/sites/monitor/share/check_mk/modules/discovery.py”, line 74, in do_discovery
    do_discovery_for(hostname, check_types, only_new, use_caches, on_error)
    File “/omd/sites/monitor/share/check_mk/modules/discovery.py”, line 94, in do_discovery_for
    new_items = discover_services(hostname, check_types, use_caches, do_snmp_scan, on_error)
    File “/omd/sites/monitor/share/check_mk/modules/discovery.py”, line 602, in discover_services
    check_types = snmp_scan(hostname, ipaddress, on_error)
    File “/omd/sites/monitor/share/check_mk/modules/discovery.py”, line 704, in snmp_scan
    result = scan_function(oid_function)
    File “/omd/sites/monitor/local/share/check_mk/checks/fgt_sslvpn”, line 52, in
    “snmp_scan_function” : lambda oid: “2” in oid(“.1.3.6.1.4.1.12356.101.12.2.3.1.1.1”),
    TypeError: argument of type ‘NoneType’ is not iterable

    Reply
  6. Hermann Maurer Post author

    please edit the file “local/share/check_mk/checks/fgt_sslvpn” and change the line 52 form

    “snmp_scan_function” : lambda oid: “2” in oid(“.1.3.6.1.4.1.12356.101.12.2.3.1.1.1”),
    to
    “snmp_scan_function” : lambda oid: oid(“.1.3.6.1.4.1.12356.101.12.2.3.1.1.1”) != None,

    Save the file and run the command to verify, if it has started working:

    cmk –debug -nvvII –checks fgt_sslvpn

    If it doesn’t help, post the output of the command above.

    Reply
    1. Nigel

      Check_MK Version: 1.2.6p12
      Page: crashed_check.py

      GET/POST-Variables:
      host=Site11_Fortigate_30E
      selection=9f0734c9-03bf-4725-ac50-31bc8733429b
      service=IPSec tunnel VPN_to_BRG
      service_regex=
      site=
      st0=on
      st1=on
      st2=on
      st3=on
      stp=on
      view_name=host

      Traceback (most recent call last):
      File “/omd/sites/entsf/share/check_mk/web/htdocs/index.py”, line 254, in handler
      handler()
      File “/omd/sites/entsf/share/check_mk/web/htdocs/crashed_check.py”, line 69, in page_crashed_check
      trace = fetch_file_from_tar(tardata, “./trace”)
      File “/omd/sites/entsf/share/check_mk/web/htdocs/crashed_check.py”, line 32, in fetch_file_from_tar
      p = subprocess.Popen([‘tar’, ‘xzf’, ‘-‘, ‘–to-stdout’, filename], stdin=subprocess.PIPE, stdout=subprocess.PIPE)
      File “/usr/lib64/python2.7/subprocess.py”, line 711, in __init__
      errread, errwrite)
      File “/usr/lib64/python2.7/subprocess.py”, line 1224, in _execute_child
      self.pid = os.fork()
      OSError: [Errno 12] Cannot allocate memory

      Reply
  7. Nelugio

    Hello. Is it possible that u could change your Plugin so it also shows each individual Accesspoint that was found? Cause it doesnt really help if it only says e.g 2 AP are down… i would like to know which ones.
    Instead of right now ( 33 up / 2 down – xx connected Clients) i would love to also have something like this

    AP_01 — up
    AP_02 — up
    AP_03 — down (crit)

    would that be possible?
    Greetings

    Reply
    1. Hermann Maurer Post author

      Thank you for your comment!
      Honestly I m not sure, if it is a good idea to generate a check for each FortiAP. In your example there 32 of them. I can imagine that it will be confusing. I guess it would only make sence, if the checks have more details per FortiAP.
      Either I would implement this or I would add names of missing FortiAP to the output of the check, I need to think more about both ideas.
      Best regards
      Hermann Maurer

      Reply
  8. Roberto

    changed fortigate_signatures

    ‘snmp_scan_function’ : lambda oid: “.1.3.6.1.4.1.12356.101.4”,
    ‘snmp_info’ : (“.1.3.6.1.4.1.12356.101.4.2”, [1, 4]),

    on firewall 5.6 IPS sigrature check to work

    Reply
    1. Hermann Maurer Post author

      Just to mention that I am not the author or a mainteiner of the check. It is likely a part of the built-in Fortigate checks.

      Reply
    1. Hermann Maurer Post author

      I consider to build a new package. I have asked in my blog for ideas, what checks the package should bring, because the build in checks work pretty well and cover almost everything.
      Please share your ideas by adding a comment to my newest blog article.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.