OPNSense HACS integration - trouble with automations

Third party integrations
1

Hi!

I am using the HACS version of the OPNSense add-on so I can get access to individual firewall rules (only enabling 443 forwarding when I really need it, and auto-closing it 5 minutes later) and wireguard connections. I am struggling with the wireguard notifications. It’s working fine when I’m staring at the screen, but I wanted to set up some automations to trigger so I will be notified even when I’m not staring at the screen.

I have OPNSense in HA, and can see the wireguard server’s client couunt entity (sensor.addisonopnsense_wireguard_server_wireguard_connected_clients) is 0 when nobody is connected, and it’s 1 when someone is connected. However, I cannot figure out how to get that to be an automation trigger.

I’ve tried several things, and only gotten confusing results.

First I did the basics: from the device page, figure out the entity I’m interested in (“sensor.opnsense_wireguard_server_wireguard_connected_clients”) and then use that as a trigger for an automation. That got me this trigger:
trigger: state
entity_id:

  • sensor.opnsense_wireguard_server_wireguard_connected_clients
    id: Handshake!

But that goes off WAY TOO OFTEN. I see it has a spiel about ‘attributes’ in the visual editor, so I selected “clients”. But I am still getting way too many triggers… I think it’s because there is a “latest check-in” or something similar that keeps triggering the automation.

How can I get the trigger to be based on ONLY the actual count of connected clients and IGNORE the additional attributes that seem to update every 30 seconds or so?

EDIT 1:
I was able to work around the problem by setting up a single automation with six triggers, one for each of my wireguard clients. Then the action is one big Choose based on which of the six trigger.id’s was fired. Each choose has been set up with a notification to my cell with the corresponding client’s entity, where I CAN find an Attribute that presents with a 1 or a 0 depending on the status of connection.

example:
message: >-
WireGuard client {{ trigger.id }} connections: {{ state_attr(“sensor.opnsense_wireguard_client_iphone_connected_servers”,“connected_servers”)
}}

But that means I need to edit this automation every time I create a new client. That’s janky. Can anyone help me figure out how to reference the VPN SERVER’s Client Count entity? (sensor.opnsense_wireguard_server_wireguard_connected_clients)

1 Like
2

I do not see a integration for Opnsense when I search in HACS , but I do see a native HASS integration that uses API.
I tried the API method and could not get it to work…

Can you confirm which Opnsense integration you are using?

I would like to get this working on my end too.

3

That’s what I’m referring to. It’s not the native integration. I got it through HACS.

4

Odd, I don’t see it

1000008027
10000080271008×469 23.9 KB

OH!, I have to add custom repo :grin:
Guess I need more coffee :sunglasses:

UPDATE: It’s an early Christmas present with 303 usable entities for open sense. I’m like a kid on Christmas morning right now looking through all the entities! :sunglasses::raised_hands::rofl:
Now I can deprecate all my SNMP entities for Opnsense!

Dashboard so far:

Screenshot from 2024-12-21 08-57-21
Screenshot from 2024-12-21 08-57-21400×868 128 KB

Thank you @mimugmail

5

Happy for you. Did you get a chance to figure out how to trigger an automation based on connection to the VPN server? I am still stuck doing a new setup for each client.

6

You can do something like this, here’s my automation yaml :

alias: phone disconnected from wire guard
description: ""
triggers:
  - trigger: state
    entity_id:
      - switch.opnsense_wireguard_client_phone
    from: "0"
    to: "1"
conditions: []
actions:
  - action: notify.mobile_app
    metadata: {}
    data:
      message: phone disconnected from wireguard
      title: "Homeassistant"
mode: single
7

Yeah that’s similar to my solution, but that means one automation per client.

There’s an entity coming into HA that’s a count of clients on the WireGuard server. I was hoping to use that to just give me a count instead of setting up a new automation for every client.

Edit: mine is called sensor.opnsense_wireguard_server_wireguard_connected_clients

8

I’m thinking we should be able to create a custom sensor for entities using a wild card match. Then use that sensor in an automation. I will play around with this later and let you know.

Maybe a custom sensor with wildcard like this:

template:
  - sensor:
      - name: "Total Connected Wired Clients"
        state: >
          {{ states.sensor | selectattr('entity_id', 'match', 'sensor.opnsense_wireguard_client_*_connected_servers') | map(attribute='state') | map('float') | sum }}
        availability: >
          {{ not 'unavailable' in states.sensor | selectattr('entity_id', 'match', 'sensor.opnsense_wireguard_client_*_connected_servers') | map(attribute='state') }}
9

Blows my mind that it’s not easy to grab that count from the server entity.

10

Actually I just checked my entities and why not use this one. It shows total concurrent connected clients and I just tested it between two devices.

sensor.opnsense_wireguard_server_opnsense_connected_clients

Maybe I’m misunderstanding your goal if you’re not looking for total wire guard connected client at any giving time.

11

That is what I’m looking for, but when I set up an automation that triggers on any change to that count, it goes off several times per hour inappropriately.

I think it’s got some detail that shows latest update and that’s considered a change that’s firing my automation.

1 Like
12

This is expected if the wireguard client connection is not persistent. I see this too with an iPhone throughout the day that uses full tunnel mode with keepalives set to 25.
If you want to notification for wireguard total connected clients, I would introduce a duration in the trigger or a conditional rule in the automation.
As you can see my total connected clients fluctuate when the iPhone is inactive / idle throughout the day.

1000008069
10000080691007×1015 97 KB

13

Not quite that simple, though. I only use wireguard when I need it, which mean’s the client count is usually 0. However, I STILL am getting frequent triggers of that automation that’s supposedly only watching the COUNT of the clients provided by the server.

14

That entity for me only reports actual active Wireguard connected clients. When all of my family is home and on wi-fi, it shows zero. However if someone leaves the house it increments accordingly. I have a road warrior setup, anytime any devices are off home Wi-Fi ssid, it connects to Wireguard via Opnsense as full tunnel.

15

Try setting up a change to that number as the trigger for an automation. Let me know whether that goes off even when the actual number doesn’t change. That’s what was happening to me.

16

Sure thing, but if I’m going to set up an automation to trigger on any change in the number then I would incorporate a conditional wait time to minimize fluctuations of client connectivity issues or now I keep alive tunnels. Also notice with iPhones and keep alive persistence, the phone still this connection wireguard when it’s inactive for a period of time

17

I dont mean long-term. Just as a brief test. When I did this before, I kept getting triggers on the “last update” instead of actual changes to the number of connected clients.
That automation would go off even when nobody was trying to be connected to my wireguard.

Maybe I was doing it wrong. I am also going to try it again since I added a few more clients yesterday and have to update the per-client automation anyway.

18

On second look, maybe I was grabbing the “clients” attribute of the entity instead of the State of the entity which should show the number of connected clients. Can you help me figure out how to trigger an automation based on the NUMBER of connected clients instead of some detail within the “Clients” attribute?

19

Here’s my new attempt:
trigger: state
entity_id:

  • sensor.opnsense_wireguard_server_wireguard_connected_clients
    id: SERVER-side
    to: