[SOLVED] Using System "Aliases" in API Created Firewall Rules

Started by utkonos, October 11, 2022, 09:22:19 PM

Previous topic - Next topic
I am trying to create firewall rules via API. I am able to create rules using CIDR, but the system aliases like "OPT1 net" or "WireGuard (Group)" or "WireGuard (Group) net" in the source_net or destination_net fields in the POST'ed JSON. Also, I'm unable to refer to the interface "WireGuard (Group)" in the interface field.

Are these strings usable in the API at all?

On a side note, when the rule is created (using CIDR and interface ID), and you look in the web console listing of "Automatically generated rules", the created rule appears to be wide open with "*" in every column on that view. However, when editing that same rule as listed under "Automation -> Filter", everything looks correct.

Is the web UI not able to display the details of the rule correctly? Or is showing all "*" in each column by design and the expected way for the rule to be displayed?

I figured out part of the answer to the first question:

"WireGuard (Group)" when referring to it via API is called "wireguard". I'm not sure if any other plugins work in the same way, but the string that the API needs is found in the config.xml section for the interface in the "if" field:

<if>wireguard</if>

And the rest of the answer to the first question: strings like "WireGuard (Group) net" and "OPT1 net" are from the descriptions and are used in the GUI to display these nets. To refer to these same entities in the API, the string to use is found in the "Name" field in the alias listings. They are listed as type "Internal (automatic)". So, the following are the translation for the two I listed with my question:

"OPT1 net" -> "__opt1_network"
"WireGuard (Group) net" -> "__wireguard_network"

and so on. As for the second question: meh. It's probably by design and is just cosmetic so it doesn't matter if it displays the correct information.

I think that traditionally the values are without the "__" underscores so that these values are directly used, not redirected over the alias which was created later for visibility (and that's why it has a double underscore to avoid clashing with existing ones).


Cheers,
Franco