Messages

Greetings.

Check out the Ansible Collection I'm maintaining: https://github.com/ansibleguy/collection_opnsense

It strictly only uses the APIs that are provided and supported by the OPNSense project: https://docs.opnsense.org/development/api.html

The API for DHCP reservations is not yet implemented though.. https://github.com/ansibleguy/collection_opnsense/issues/45

If you take the risk of editing the raw XML-config - you could also checkout this Ansible Collection: https://github.com/puzzle/puzzle.opnsense (I can not recommend that)

BTW: I'm just processing a PR to allow Ansible-management of those  :)
https://github.com/ansibleguy/collection_opnsense/pull/84

Greetings!

I just want to mention the Ansible Collection I am developing: https://github.com/ansibleguy/collection_opnsense

It utilizes the REST APIs provided by OPNSense - therefor it has some limitations, but it is applicable for many common use-cases.

- AnsibleGuy

Hi.

It seems the IPSec API is actually on its way: https://github.com/opnsense/core/pull/6187#issuecomment-1356263118

- AnsibleGuy

Hi.

Looks like some major updates to the IPSec implementation are being done: https://github.com/opnsense/core/pull/6187

Those might allow API management in the future.

- AnsibleGuy

Hi.

FYI:

• os-firewall gateway-groups not available: https://github.com/opnsense/plugins/issues/3139
• os-firewall aliases in use can be deleted: https://github.com/opnsense/plugins/issues/3140
• unbound query-forwarding: https://github.com/opnsense/core/issues/6047

- AnsibleGuy

Hi.

Thank you for your response.  :)

You are right - I'll open tickets regarding my findings. Makes sense.

I just wanted to ask beforehand as I could've overlooked something.

- AnsibleGuy

Hi.

The missing GW-Groups make the API 'unusable' for many practical use-cases.  :'(

@Fright would you know something about that functionality?

As I have not got much experience developing PHP I'm not really able to read into the OPNSense code  :-\

- AnsibleGuy

Hi.

FYI: If you have trouble using some OPNSense API - I've implemented many of the available ones in my project => https://github.com/ansibleguy/collection_opnsense

One could use the Ansible modules directly or read into (the code) how to use the APIs.  :D

- AnsibleGuy

[automation rules]

Hi.

I'm back again ;D

Today I have a question regarding the automation/api-managed rules.

API reference: https://docs.opnsense.org/development/api/plugins/firewall.html


Someone reported to me that in those rules one cannot choose a gateway group as target-gateway.

Per example:
1. Using the automation rules:


2. Using the default web-ui rules:


Can someone tell me whether this is intentional or that's a bug/missing functionality?  ???

Anyway - this is a very commonly used functionality and therefore would be nice to be available using the API.

- AnsibleGuy

Hi.

As I would love to create an Ansible Module (https://github.com/ansibleguy/collection_opnsense) to manage IPSec tunnels => are there updates regarding the IPSec API?

Is there a plan to API-enable it in the future?

- AnsibleGuy

Hi.

If 'dot*' are non-deprecated methods/endpoints we should add it to the docs: https://docs.opnsense.org/development/api/core/unbound.html

I'm satisfied - it works ;D

- AnsibleGuy

Hi.

We solved it somehow.

It seems if you target the deprecated 'addDot' API endpoints - it works.

Code Select Expand


REQUEST: POST | HEADERS: '{'Referer': 'https://FW/ui/unbound/forward', 'Content-Type': 'application/json'}' | URL: https://FW/api/unbound/settings/addDot | DATA: {'dot': {'type': 'forward', 'enabled': 1, 'domain': 'tmp.at', 'server': '1.1.1.1', 'port': 53}}


The type seems to only be set to the 'Referer' value if the target method does not exist.. (?)  :-\

- AnsibleGuy

Hi.

First of all - thank you for your help! :)

Hmm.. interesting.

I understand the usage of 'Referer' when using the WEB-UI, but it seems to be a little out-of-place for API-only usage.

However - I tested setting the 'Referer' header manually - but without luck.

Code Select Expand


REQUEST: POST | HEADERS: '{'Referer': 'https://FW/ui/unbound/forward', 'Content-Type': 'application/json'}' | URL: https://FW/api/unbound/settings/addForward | DATA: {'dot': {'type': 'forward', 'enabled': 1, 'domain': 'tmp.at', 'server': '1.1.1.1', 'port': 53}}


The dot-items are still of type 'dot'..  :-\

- AnsibleGuy

Hi

I'm back with another question  ;D

Currently I'm working to implement the Unbound API as Ansible Module.

API References:

• https://docs.opnsense.org/development/api/core/unbound.html
• https://github.com/opnsense/core/blob/master/src/opnsense/mvc/app/models/OPNsense/Unbound/Unbound.xml

The 'Query Forwarding' is not working as I would expect.

In the XML - there is a 'type' switch between 'dot' and 'forward':

Code Select Expand


<type type="OptionField">
  <Required>Y</Required>
  <default>dot</default>
  <OptionValues>
    <dot>DNS over TLS</dot>
    <forward>Forward</forward>
  </OptionValues>
</type>


This can also be seen in the 'get' response:

Code Select Expand

"type":{"dot":{"value":"DNS over TLS","selected":0},"forward":{"value":"Forward","selected":1}

But I my 'dot' items always get created as 'dot' types.
Example:

Code Select Expand


REQUEST: POST | HEADERS: '{'Content-Type': 'application/json'}' | URL: https://FW/api/unbound/settings/addForward | DATA: {'dot': {'type': 'forward', 'enabled': 1, 'domain': 'tmp.at', 'server': '1.1.1.1', 'port': 53}}
RESPONSE: {'status_code': 200,... '_content': b'{"result":"saved","uuid":"..."}'}


Without the 'dot' key in the payload it fails. When changing that key to a 'forward' - it fails.
Can someone enlighten me on what I'm doing wrong?  :-\

- AnsibleGuy