Gateway status via API

[matthew-on-git]

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[-] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md

[-] I have searched the existing issues and I'm convinced that mine is new.

Is your feature request related to a problem? Please describe.
I have a problem in that opnsense continues to advertise a default route to downstream routers via OSPF, even when the gateway status is down. (Forum post)I understand that frr doesn't know about gateway status, so I am attempting to write an auto remediation script that will check the status of the gateway and tell opnsense to stop advertising default gateways. The issue is that the opnsense API doesn't seem to have an endpoint for getting the gateway status.
I have checked the API docs for this and not found it as well as have found multiple forum posts asking how this can be done, that have been unanswered. example

Describe the solution you'd like
I would like an API endpoint for doing a GET of gateway statuses similar to firmware status for instance. e.g. https://opnsense.host.fqdn/api/core/firmware/status
It might return a list of gateways monitored an their status at a minimum, but could also provide more info like description etc.

Describe alternatives you've considered
The alternative I first tried was just getting OSPF to stop advertising on it's own, but the option doesn't seem to be there.

I could also try a ping based option I suppose, but the ping would have to run from opnsense. I may try this.

Additional context
search for gateway status api on the forums for others asking for this

[AdSchellevis]

is the output of pluginctl -r return_gateways_status what your looking for?

[matthew-on-git]

is the output of pluginctl -r return_gateways_status what your looking for?

This is exactly the output I am looking for. It would be better if it was available via api, so I could run my remediation from a third party box, but this solves my immediate need, and I should be able to run a local script.

Where is this documented? I have had a hard time finding cli command documentation.
THANKS!!!

[matthew-on-git]

To be more clear, I was hoping to build this into a python lambda in AWS. Not the end of the world, and I know there are ways to run cli over ssh...

[AdSchellevis]

It's not very difficult to add an endpoint for it (map to a configd call and add a controller), usually I only add them if there's a consumer inside the product as well (either a widget or a user screen), let's keep this issue open and I'll think about it for a bit

[AdSchellevis]

@matthewmdn there you go 89cfc06 , adds http[s]://[host]/api/routes/gateway/status endpoint and uses it in the gateway widget as well.

[matthew-on-git]

It's not very difficult to add an endpoint for it (map to a configd call and add a controller), usually I only add them if there's a consumer inside the product as well (either a widget or a user screen), let's keep this issue open and I'll think about it for a bit

The interesting thing is that there is a widget, so I had just assumed in my planning it would be available in the API.

[AdSchellevis]

Most widgets use legacy code feeds, we haven't refactored the dashboard (except major code cleanups). Since the pluginctl call didn't return all the data the widget needs, I've moved it into it's own spot for configd to collect (otherwise configd would just have called the return_gateways_status as described earlier).

[richard-parker]

@matthewmdn there you go 89cfc06 , adds http[s]://[host]/api/routes/gateway/status endpoint and uses it in the gateway widget as well.

Excellent, thanks for adding support for this @AdSchellevis! Do you know when it is scheduled for release, or if it's available in a dev version as yet? I couldn't see it listed in the 21.1 milestone, but could be missing something. Thanks!

[AdSchellevis]

@richard-parker your welcome, I expect this to land somewhere in 20.7.4 or 20.7.5. I did add the item to our roadmap recently (https://opnsense.org/about/road-map/) by the way.

[richard-parker]

@AdSchellevis fantastic; looking forward to getting the update soon. I see you've added it to the roadmap page under 21.1, along with a ton of other cool stuff, too. Cheers!

[toxic0berliner]

Hello,

I was lookting to do this exact same thing (have a graph in netdata to show status of my several gateways)

Sadly, for some reason this pluginctl -r return_gateways_status command returns not all gateways and it claims they are all down, when in fact some of them are up :

 pluginctl -r return_gateways_status
{
    "dpinger": {
        "VPN_XXX_XX_VPNV4": {
            "name": "VPN_XXX_XX_VPNV4",
            "status": "down",
            "stddev": "~",
            "delay": "~",
            "loss": "~"
        },
        "VPN_XXX_XXX_VPNV4": {
            "name": "VPN_XXX_XXX_VPNV4",
            "status": "down",
            "stddev": "~",
            "delay": "~",
            "loss": "~"
        },
        "VPN_PIA_FR_XXX_VPNV4": {
            "name": "VPN_XXX_FR_XXX_VPNV4",
            "status": "down",
            "stddev": "~",
            "delay": "~",
            "loss": "~"
        },
        "VPN_PIA_FR_XX_VPNV4": {
            "name": "VPN_XXX_FR_XX_VPNV4",
            "status": "down",
            "stddev": "~",
            "delay": "~",
            "loss": "~"
        },
        "WAN_XXX_DHCP": {
            "name": "WAN_XXX_DHCP",
            "status": "down",
            "stddev": "~",
            "delay": "~",
            "loss": "~"
        },
        "WAN_XX_DHCP": {
            "name": "WAN_XX_DHCP",
            "status": "down",
            "stddev": "~",
            "delay": "~",
            "loss": "~"
        }
    }

Where in fact, in the GUI, I got the correct status and full list of gateways. The ones not showing up in pluginctl are the ones that are disabled, fine, I can go with that, but they are not done, in fact 3 of them are up (green), 2 of them are down (red) and the last one has latency (orange).

on the dashboard, dpinger is shown as running for all non-disabled interfaces and it is down for the disabled ones.

So somehow this pluginctl is not picking the proper data.

I undrestand this is an enhancement request, so not the place to submit what looks like a bug, but in fact I don't really care about the pluginctl thing, I'd much more like this API enhancement provides the proper data ;) Just pointing that out here so you can source the proper gateway status for the API calls.

[toxic0berliner]

Sadly, for some reason this pluginctl -r return_gateways_status command returns not all gateways and it claims they are all down, when in fact some of them are up :

Got that wrong, sorry, it works fine, it just needs to be run with proper permissions... with root it works just nice ;)

[richard-parker]

This just landed in the update; looks fab. But unless I'm missing something, how can you tell which one is the 'active' gateway from the response?

{
    "items": [
        {
            "name": "Primary",
            "address": "xxx.xxx.xxx.xxx",
            "status": "none",
            "loss": "0.0 %",
            "delay": "13.5 ms",
            "stddev": "2.1 ms",
            "status_translated": "Online"
        },
        {
            "name": "Backup",
            "address": "xxx.xxx.xxx.xxx",
            "status": "none",
            "loss": "~",
            "delay": "~",
            "stddev": "~",
            "status_translated": "Online"
        }
    ],
    "status": "ok"
}`

[Bubbgump209]

What permissions are required to query this status via the API? none of the below seem to be adequate:

| GUI | Diagnostics: Logs: Gateways
| GUI | System: Gateway Groups
| GUI | System: Gateways
| GUI | System: Gateways: Edit Gateway
| GUI | System: Gateways: Edit Gateway Groups

EDIT: Disregard. Future Googlers, this requires "GUI | Dashboard (widgets only)"