Features that you would like to see

[FG1kc]

Why limit to Authentication-based routing,can' t fortinet have Address-based and Device Identity routing on the policy tab itself rahter than putting it on the policy route tab would be very nice to have when your using/have multiple gateways

[Christopher_McMullan]

It doesn' t look like the decision on which real integer is used to store the policy in configuration is made until ' end' commits it to the running or startup config. Look at the output when the CLI debug level is set to 8: McFortiGate # di de reset McFortiGate # di de en McFortiGate # di de cli 8 McFortiGate # conf firewall policy McFortiGate (policy) # edit 0 new entry ' 0' added McFortiGate (0) # set srcintf FortiLAN path=firewall, objname=policy, size=1388, sz_attr=1 McFortiGate (0) # set dstintf wan1 path=firewall, objname=policy, size=1388, sz_attr=1 McFortiGate (0) # set srcaddr all path=firewall, objname=policy, size=1388, sz_attr=1 McFortiGate (0) # set dstaddr all path=firewall, objname=policy, size=1388, sz_attr=1 McFortiGate (0) # set schedule always path=firewall, objname=policy, size=1388, sz_attr=1 McFortiGate (0) # set service ALL path=firewall, objname=policy, size=1388, sz_attr=1 McFortiGate (0) # set action accept path=firewall, objname=policy, size=1388, sz_attr=1 McFortiGate (0) # set nat en path=firewall, objname=policy, size=1388, sz_attr=1 McFortiGate (0) # end cmd_clean_context 0, abort=0 McFortiGate # write config file success, prepare to save in flash [__create_file_new_version:560] the new version config file ' /data/./config/vd_root_firewall_policy.gz.v000000076' is created [symlink_config_file:627] a new version of ' /data/./config/vd_root_firewall_policy.gz' is created: /data/./config/vd_root_firewall_policy.gz.v000000076 [symlink_config_file:670] the old version ' /data/./config/vd_root_firewall_policy.gz.v000000075' is deleted [symlink_config_file:673] ' /data/./config/vd_root_firewall_policy.gz' has been symlink' ed to the new version ' /data/./config/vd_root_firewall_policy.gz.v000000076' . The old version ' /data/./config/vd_root_firewall_policy.gz.v000000075' has been deleted zip config file /data/./config/vd_root_firewall_policy.gz success! The context of policy 0 is ' cleaned' after typing ' end' , and the rest of the output notes that a new file has replaced the old file. It looks like it would be *theoretically* possible to try piping the output of the new file created to another container, and by script, parse the file to see the diff between the old and new configs, and pull the policy ID from that file at the bottom of the ' config firewall policy' section, if you really wanted to know right away. Even here, though, it' s after ' end' is typed. I don' t think the kernel handles the process of policy creation in a way that it could note the real number before the full policy is committed.

[journeyman]

' next' or ' end' or doesn' t matter? next isn' t needed in your example, but not sure if that changes things. After the edit 0 reply was posted I tried to find it documented (only in the kb). I found a script example where multiple policies were added using edit 0; they were added in a block with one end statement. I hope that works because it will be very handy for scripting. It would be nice if the real policy ID was printed to the console at some stage in the edit process, and yes, ideally at the ' added' message.

[Christopher_McMullan]

It doesn' t matter between ' next' or ' end' ...both are statements which will commit a change to the configuration. Using ' next' will return you to the context you' re already in, i.e., ' config firewall policy' or ' config router static' , whereas ' end' will return you to the root of the CLI *or* the last point where you used the verb ' config' . It' s not that we don' t want to entertain an NFR for citing a real policy number earlier on in the process - I don' t think it' s even possible. Even thinking about the theoretical implications, the kernel will do a sanity check on the policy before committing it. To have a policy numbered before entering any options would mean modifying a policy which now has a number and a place within the order of the rest of your rules. What would happen to the kernel if it had a policy in the list with *no* other settings defined, or worse yet, the wrong settings, that would trigger a CLI error code after typing ' next' or ' end' , ultimately leaving the new object discarded? I' m not a developer, but I could see the way, just by knowing the order that a policy or new object is applied in, how this probably wouldn' t work, nice as it may be.

[netmin]

I like this discussion, so let me add my 2 cts, _when_ the kernel knows, which policy number is to be added:

 login as: admin
 FortiGate-VM64 # config firewall policy
 
 FortiGate-VM64 (policy) # edit 0
 new entry ' 0'  added
 
 FortiGate-VM64 (0) # show
 config firewall policy
     edit 3
     next
 end
 
 FortiGate-VM64 (0) #
 

[Christopher_McMullan]

Ah... Never underestimate the SHOW.

[journeyman]

Excellent - so next release then ;)

[nbctcp]

this one always start with 1 i.e

config firewall policy

edit 1

if you type edit 0, it will shown as 1

FR: -allow tarpit

-allow port knocking

- | grep -f not available in FortiAnalyzer FortiMail, most probably other than FortiGate

login as: admin
# config firewall policy
(policy) # edit 0
new entry ' 0' added
(0) # show
config firewall policy
edit 3
next
end

[ede_pfau]

Multiple ' edit 0' do work, even before the final ' end' . So, there is some internal housekeeping done right after the ' edit 0' command. Shouldn' t be too difficult to implement.

[ede_pfau]

very cool, Hut ab!

[Istvan_Takacs_FTNT]

Proper CLI navigation similar to JunOS where Ctrl+W/E/U/etc. does what it supposed to and not just deletes the entire line. When I search for an option/value in CLI then to display the location of it, instead of using | grep -2000 <search term> then to scroll back to try to find the location of it. Same for all the diagnose commands. If I want to find an option to debug what I want, without having access to the CLI guide, or to use the ' tree diagnose' command and scroll through potentially hundreds of lines, but rather to have a search option that tells me how I can get to the specific command. Have the history available in CLI of the last few configuration changes made and an option to rollback to any of them with a simple option, similar again to JunOS " show | compare rollback <previous revisionX> <previous revisionY>" and " rollback <revision #>"