Skip to content

FortiOS: Allow any policy#3324

Open
a-v-popov wants to merge 1 commit intoipspace:devfrom
a-v-popov:fos-allow-any
Open

FortiOS: Allow any policy#3324
a-v-popov wants to merge 1 commit 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).


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

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