Skip to content

FortiOS: Allow any policy#3324

Merged
ipspace merged 3 commits intoipspace:devfrom
a-v-popov:fos-allow-any
Apr 15, 2026
Merged

FortiOS: Allow any policy#3324
ipspace merged 3 commits intoipspace:devfrom
a-v-popov:fos-allow-any

Conversation

@a-v-popov
Copy link
Copy Markdown
Collaborator

@a-v-popov a-v-popov commented Apr 13, 2026

This is possible variant to address #3323

Policy is injected in initial configuration.

It is configured by device configuration:

$ cat ~/.netlab.yml 
---
devices.fortios:
  group_vars:
    netlab_allow:
      disable: false

Copy link
Copy Markdown
Owner

@ipspace ipspace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lovely idea. I would make a few slight changes in the variable names and streamline the tests.


{# End of `config global` #}

{% if netlab_allow is defined and netlab_allow != false %}
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would call it "netlab_default_policy" or some such, and generate the firewall policy if the variable is defined.

If you want to have an override option (setting it to false to disable it), go with netlab_default_policy|default(false)-- that will be false if the variable is not defined or if it's set to False, and will evaluate to false as a boolean expression even if it has falsy value (like None or an empty dictionary).

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem would be an empty dict, or rather an abuse of YAML like this:

$ cat ~/.netlab.yml 
---
devices.fortios:
  group_vars:
    netlab_default_policy:
      #enable: false

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even that works, see my test results for the "None" value ("YAML abuse" results in None value).


config firewall policy
edit 1000
{% if netlab_allow is mapping and netlab_allow.disable | default(false) %}
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At this point, we know "netlab_default_policy" (or however it's called) is defined. Under our current Jinja2 setup, you could simply test netlab_default_policy.disable|default(false) and have the desired result even when netlab_default_policy is not a mapping.

Personally, I would prefer using enable with default true, "not disabling" is a double negation, and that tends to get confusing.

@ipspace
Copy link
Copy Markdown
Owner

ipspace commented Apr 13, 2026

Here's how you can test whether any particular trick works with our Jinja2 setup. As we are using the same code to generate reports and device configs, you can create a report that uses none of the topology variables and play with Jinja2 expressions. The only tricks:

  • The report has to be in reports directory and have .j2 extension
  • There should be topology.yml file or a started lab in the current directory

After setting this up, just do netlab report reportname and experiment.

Here's what I tested:

{% set tv = true %}
{% set fv = false %}
{% set sv = "abc" %}
{% set nv = None %}
{% set mv = {'a': true, 'b': false} %}

tv: {{ tv }} tv.a: {{ tv.a|default('DEFAULT') }}
fv: {{ fv }} fv.a: {{ fv.a|default('DEFAULT') }}
sv: {{ sv }} sv.a: {{ sv.a|default('DEFAULT') }}
nv: {{ nv }} nv.a: {{ nv.a|default('DEFAULT') }}
mv: {{ mv }} mv.a: {{ mv.a|default('DEFAULT') }} mv.x: {{ mv.x|default('DEFAULT') }}

And here are the test results:

% netlab report j2test
[INFO]    Using lab topology file topology.yml

tv: True tv.a: DEFAULT
fv: False fv.a: DEFAULT
sv: abc sv.a: DEFAULT
nv: None nv.a: DEFAULT
mv: {'a': True, 'b': False} mv.a: True mv.x: DEFAULT

@a-v-popov
Copy link
Copy Markdown
Collaborator Author

a-v-popov commented Apr 14, 2026

I added a commit based on the feedback.
If anything else is required or a change in a workflow is need please let me know.

@ipspace
Copy link
Copy Markdown
Owner

ipspace commented Apr 15, 2026

I added a commit based on the feedback.

Thank you.

If anything else is required or a change in a workflow is need please let me know.

Documentation ;) Just kidding, I added it. Merging...

Copy link
Copy Markdown
Owner

@ipspace ipspace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ready to merge. Thank you!

@ipspace ipspace merged commit 5c0f25d into ipspace:dev Apr 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants