Firewall rule Creation through API or CLI

[athisesanr]

Greetings,

I was curious if there was a way to add firewall rules from the command line/console?
Apologies if this has been answered elsewhere, however I could not find anything through my forum search.

Version: OPNsense 24.1.4-amd64

Regards.
Athisesan R

[athisesanr]

Hi Folks,

Anyone can assist here to find the cli format of creating rules/nats. I been looked more forum there are no clueless. I hope there are no easy rules type here that what PfSense followed.

Also, I just verified some API docs that only focus the Automation Filter rules not an exact Floating and Interface rules directly.

Automation filter rules doesn't supports Allies options there.

below docs only focused automation filter rules instead of interface own or floating rules,
https://docs.opnsense.org/development/api/plugins/firewall.html
https://docs.opnsense.org/development/api/core/firewall.html

Thanks,
Athisesan R

[barold]

Hi there,

PF is document here https://www.openbsd.org/faq/pf/. Making use of that within OPNsense is another story.

I've done some study, but I'm sure many other people know a whole lot more.

OPNsense seems to configure PF in the PHP code found mostly in two places: /usr/local/opnsense/mvc/app/library/OPNsense/Firewall/Plugin.php and /usr/local/etc/inc/filter.inc. It seems to do it based on the contents of /conf/config.xml. I have no idea how one would hook into that machinery. There is a suggestion in the code that some anchors are configurable; Plugin#anchorToText is called when the code builds the final rules. However, I've been unable to find any code calling Plugin#registerAnchor, which would have set something up for the anchorToText call. You can read the PF reference to learn how anchors could have helped you had they existed in strategic places.

The code does leave all the rules that are generated in the file /tmp/rules.debug. The lines in that file are in the syntax that PF expects. After the code builds that file, it runs "pfctl -f /tmp/rules.debug". You could craft your own file, xyz, and put a script in /usr/local/etc/rc.syshook.d/start, which would run after the firewall is setup and replace what it configured by running "pfctl -f xyz". But that seems pretty dangerous except for someone who is extremely knowledgable.

Then again, I could be completely wrong about everything. :) I've been watching this thread since you started it, hoping someone who actually knows something chimes in. I hope my post is not a complete waste of your time.

Regards,
Barold

[athisesanr]

Hi Barlod,

thanks for reverts.,

doing pfctl -f thing will flush and config.xml edit will not possible while system live as what i understands. however, I'm trying to fine exact cli or api rules where can directly post interface own or floating as get/post/delete/modify instead of /api/firewall/filter/getRule


flush ALL   pfctl -F all
flush only the RULES   pfctl -F rules
flush only queues   pfctl -f queue
flush only NAT   pfctl -F nat
pfctl -F info   flush all stats that are not part of any rule


also, keep searching any other forums will give exact path to find the solutions at least in cli level.!!

Relevant forum,
https://forum.opnsense.org/index.php?topic=3553.0
https://forum.opnsense.org/index.php?topic=16943.0
https://forum.opnsense.org/index.php?topic=6415.0

Thanks,
Athisesan R

[barold]

OK. I think I misunderstood your request for the cli format. I thought you wanted to understand the syntax for pfctl. I'd be very interested to learn if OPNsense provides an API for modifying, inserting, or deleting rules.

I see this might not be your desire, but if you were to use pfctl yourself and regarding loading the main ruleset on a running system, consider this excerpt from an article at http://undeadly.org/cgi?action=article&sid=20060929080943...

"""
There's no need to flush rules before loading a new ruleset like

  $ pfctl -Fr -Fn -f /etc/pf.conf

In fact, this not only wastes CPU cycles, but introduces a (brief) temporary state with no rules loaded, when packets might pass that both the old and the new ruleset would block. A simple invokation with -f is sufficient and safe: while the new ruleset is being uploaded to the kernel, the old ruleset is still in effect. Once the new ruleset is completely uploaded, the kernel switches the rulesets and releases the old set. Any packet, at any time, is either filtered by the entire old ruleset or the entire new ruleset. If the upload fails for any reason, the old ruleset remains intact and in effect.

There are no pfctl commands to add or remove individual rules from a loaded ruleset. However, the output of pfctl -sr is valid input for pfctl -f. For instance, additional rules can be inserted at the beginning or end of the ruleset using:

  $ (echo "pass quick on lo0"; pfctl -sr) | pfctl -f -
  $ (pfctl -sr; echo "block all") | pfctl -f -
"""

[Patrick M. Hausen]

Two hints:

1.

Don't use the OpenBSD documentation for pf(4). FreeBSD import of that module was quite some years ago and the two implementations have diverged significantly. Refer to the FreeBSD docs if you need anything beyond OPNsense's own documentation.

2.

The OPNsense project is from the start on a journey to rewrite the entire forked pfSense code with a new MVC based implementation that provides an API for literally everything.

Unfortunately the entire firewall rule section is still "old style" PHP with HTML and PHP intermingled in a "web page".

If you browse the code you will find the finished modules with the new implementation and an API in src/opnsense/mvc while the old UI resides in src/www.

Sorry to bring bad news, but there is no API, yet.

Kind regards,
Patrick

[athisesanr]

Hi Patrick  ;)

I ve received this information when I inspect the UI and still to be try to understand is there any norms to be supported in business edition with restful API for all UI taps?

Also, i just started to edit the config.xml file where I need rules and nats (outbound & 1:1) which is working without full restart.

Anyhow I may recheck with you that config.xml edit is good practice? lets we do have governance and QA during the edits and does it helpful till the full api release?

Thanks,
Athisesanr

[Patrick M. Hausen]

I ve received this information when I inspect the UI and still to be try to understand is there any norms to be supported in business edition with restful API for all UI taps?

No - the business edition is based on the same source code. This is an ongoing multi-year effort by the development team. MVC/API migration is simply not done yet.

If you look at the roadmap you get an impression what was done in the last release and what is up for the next one.

If you have a business case and possibly even a budget there might be a way to persuade Deciso to prioritise things differently. ;) I'd contact them directly in that case.

Also, i just started to edit the config.xml file where I need rules and nats (outbound & 1:1) which is working without full restart.

Anyhow I may recheck with you that config.xml edit is good practice? lets we do have governance and QA during the edits and does it helpful till the full api release?

I am not qualified to answer that one although I have also hacked config.xml in the past and continue to do so in my Vagrant based development environment.

HTH,
Patrick

[franco]

os-firewall supplemental plugin was offering API for rules for quite a while. Since 24.1 it's part of core and also added support for NPT as a general replacement for existing static pages (no API support).

The remaining static pages will be migrated eventually, but not on the immediate radar for 24.7 as we shift priorities to different components to avoid trying to offer a 2 year roadmap with all of it being a single component.

Yes, all of this API conversion is a tremendous amount of work so we will likely be doing it for a few more years, but there is light at the end of a tunnel after almost a decade of work :)


Cheers,
Franco

[athisesanr]

Hi,

Many thanks Franco and Patrick for brief view on API part. and the thought to consider XML edit with particular portion such as nat/rules and ipsec legacy alone till the full function api available in opnsense system.

Thanks,
Athisesan R