API Firewall Rule management

[ansibleguy]

Hello (:

I'm currently developing Ansible RedHat modules to manage OPNSense firewalls using their API.
See: https://github.com/ansibleguy/collection_opnsense

As far as I have understood the API documentation - there is currently 'only' a non-core support for managing Firewall-Rules using the API, right?
See: https://docs.opnsense.org/development/api/plugins/firewall.html

But it seems this integration lacks some very important features - as there is no support for aliases. :-\
(please correct me if I'm wrong..)

Does anybody know if there is a more complete API integration on the roadmap?
If so - can you point me to some information/statements?

Thanks
- AnsibleGuy

[Fright]

Hi
from what i see in the model
(https://github.com/opnsense/plugins/blob/master/net/firewall/src/opnsense/mvc/app/models/OPNsense/Firewall/Filter.xml)
aliases IS supported in source and destination fileds

[ansibleguy]

Hi.

Seems you are right - thanks for the input.
Ports don't take aliases - but one can add them to the source_net or destination_net fields.

I was confused as the fields have the explicit term 'net' in them.  ???

What is interesting is that you CAN delete aliases that are currently referenced by those 'automation' rules.  :-\

[Fright]

Hi

What is interesting is that you CAN delete aliases that are currently referenced by those 'automation' rules.

hm..looks like it is. may be additional check (in Filter model) should be added at
https://github.com/opnsense/core/blob/7601e9cab3badfd78673bee3f486f8cb9f092266/src/opnsense/mvc/app/models/OPNsense/Firewall/Alias.php#L129

[mimugmail]

If this project sticks to api-only and no XML hacking this sounds very promising

[ansibleguy]

Hi.

hm..looks like it is. may be additional check (in Filter model) should be added at
https://github.com/opnsense/core/blob/7601e9cab3badfd78673bee3f486f8cb9f092266/src/opnsense/mvc/app/models/OPNsense/Firewall/Alias.php#L129

Would make sense - yeah.
For now I'll implement a client-side check for this edge-case.

Thanks for now (:
- AnsibleGuy

[ansibleguy]

Hi

If this project sticks to api-only and no XML hacking this sounds very promising

That's the plan. ;D
I like the approach of best-practise Ansible - were you 'touch' as little as possible.
The XML-way seems to be the opposite of that..

- have a nice day
AnsibleGuy

[Vesalius]

Interesting, watching on GitHub.

[ansibleguy]

Hi.

I found another buggy behaviour of the plugin when creating IPv6 rules:

Code Select Expand

REQUEST: POST | HEADERS: '{'Content-Type': 'application/json'}' | DATA: {'rule': {'enabled': 1, 'sequence': 1, 'action': 'pass','quick': 1, 'interface': 'lan', 'direction': 'in', 'ip_protocol': 'inet6', 'protocol': 'TCP', 'source_not': 0, 'source_net': 'any', 'source_port': '', 'destination_not': 0, 'destination_net': 'any', 'destination_port': '443', 'log': 1, 'description': 'ANSIBLE_TEST_1_10'}}

Code Select Expand

RESPONSE: {'status_code': 200, ... '_content': b'{"result":"saved"...

But the 'TCP/IP Version' of the rule is set to inet/IPv4..  :(

[Fright]

hi

'ip_protocol': 'inet6'

"ipprotocol" may be?

[ansibleguy]

Hi.

Thanks - I'll try it.

Sorry, I could've sworn the 'searchRule' endpoint also returned it with an underscore.  ???

Maybe it's time to get some sleep  ;D

- AnsibleGuy

[joinnowuk]

I was confused as the fields have the explicit term 'net' in them.  ???  install vidmate get-mobdroapk.com

[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

[Fright]

Hi
looks like a regression at
https://github.com/opnsense/core/commit/6832fd75a0b41e376e80f287f8ad3cfe599ea3d1#diff-a3952cd78b5ddaabed637d6331fbd16ec8f4d04bba06f6689b991493156fb66e
"type" is set based on Referer Header

[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