Firewall Description Character Limit in 1.4.0-epa1

When upgrading from 1.3 to 1.4 one of the errors was that firewall name descriptions had to be under 256 characters. While this is reasonable, is it necessary to limit it to such? I use the descriptions to provide an overview that can be use to quickly audit the rules below (new FTC requirements…), over 256 characters is sometimes necessary, also it caused errors when upgrading from 1.3.5 to 1.4.

Thank you.

Hi @personline,

In 1.4 the firewall was moved to the new XML representation for the CLI which makes use of „building blocks“ for several common CLI nodes (like description). This building block comes with the 256 character limitation - as I felt might be sufficient - and also some other parts only support 256 characters (like Kernel interface alias).

I think when you do a full documentation you are even better off using the comment command on the CLI tree rather then description. Nevertheless it should not produce an error during configuration upgrade.

Issue tracked via ⚓ T6071 firewall: CLI description limit of 256 characters cause config upgrade issues

IMHO if your FW description needs more than 256 chars then “you are doing it wrong” :wink:

1 Like

Thank you c-po, makes sense. I’ll look at the comment command.

Yes, Apachez, I would agree with you, but to prevent mistakes in some areas we have rather verbose descriptions of firewall rules so that when audited it serves as a guide. Per new FTC regulations we have to audit firewall rules regularly and justify their existence, to me doing this is in the CLI and having a “header” with an overview makes it easier to process. The lengthy description I’m referring to isn’t per rule, it’s for the zone based firewall name such as

set firewall name ZONE1.ZONE2 description "sometimes verbose description of all firewall rules under this firewall name, and reasons for their existence + timestamp"

I wasn’t aware of the comment option and will see what that looks like :slight_smile:

In my world the description only contain date, user and which case for reference.

Something like:

240227: 9948 /Apachez

21 chars in above but sure they can probably grow to the double depending on username and number of digits in the caseid. But 256?

Then in the caseid 9948 you can have all the words and docs FTC and others would like for traceability.

While for regular ACL’s the remarks are written with caps only (easier to read when doing various show commands) and ACE’s are grouped per function or system.

Something like:

150 remark PUBLIC DNS-SERVERS

That works as well. I assume people are lazy, because I am lazy and when wore out will pursue the path of least resistance, so trying to make it easy on myself and others who have to review rules regularly.

Doing the command:

show firewall name WRKSTN.PRIV_SVR_C

And seeing:

default-action drop
 description "WRKSTN to PRIV_SVR_C: STOCK, <WIN_DC-TCP>(WIN_DC-IP), <WIN_DC-UDP>(WIN_DC-IP), <WIN_NPS-UDP>(WIN_NPS01-IP), <WIN_CA-TCP>(WIN_CA02-IP), <OPENFIRE-TCP>(OPENFIRE-IP) ###Rules Generated 2023-10-19 09:42:45.550507###"
 enable-default-log
 rule 100 {
     action accept
     description "Allow established/related"
     log disable
     state {
         established enable
         related enable
     }
 }
 rule 105 {
     action drop
     description "Drop invalid"
     log enable
     state {
         invalid enable
     }
 }
 rule 110 {
     action accept
     description "to WIN_DC-TCP to WIN_DC-IP"
     destination {
         group {
             address-group WIN_DC-IP
             port-group WIN_DC-TCP
         }
     }
     log enable
     protocol tcp
     state {
         new enable
     }
 }
 rule 115 {
     action accept
     description "to WIN_DC-UDP to WIN_DC-IP"
     destination {
         group {
             address-group WIN_DC-IP
             port-group WIN_DC-UDP

........

allows me to go back and forth through the same screen and understand what I’m looking at from the summary and what I should be seeing in each rule. If someone has gone in a modified/added/removed something it will be easy to spot from once screen. If the world is at peace and I’ve had enough rest then I’ll be ambitious and check my offline documentation against what I see in the config.

Same thing when reviewing the config file directly:

    name WRKSTN_WIFI.PRIV_SVR_F {
        default-action drop
        description "WRKSTN_WIFI to PRIV_SVR_F: STOCK, <BDYSHP_SVR-TCP>(BDYSHP_SVR-IP), <BDYSHP_SVR-UDP>(BDYSHP_S
VR-IP) ###Rules Generated 2023-10-19 09:42:45.550507###"
        enable-default-log
        rule 100 {
            action accept
            description "Allow established/related"
            log disable
            state {
                established enable
                related enable
            }
        }
        rule 105 {
            action drop
            description "Drop invalid"
            log enable
            state {
                invalid enable
            }
        }
        rule 110 {
            action accept

If there is another way of summarizing for the purpose of spot checking which requires the same or less effort I’d like to see it. I’m trying to build a Toyota (from the early 2000s), even though BMWs are more fun to drive.

The comments command might be an alternative but I have’t used it and am unsure how to use it, it doesn’t appear to be a part of the firewall syntax.

Instead of set firewall name EXAMPLE rule 105 desciption "yadayada", you would do comment firewall name EXAMPLE rule 105 action "yadayada" to place the comment within the rule.

Example:

vy1@vyos# comment firewall ipv4 forward filter rule 10 action adasdasd
[edit]
vy1@vyos# show firewall ipv4 forward filter rule 10
+/* adasdasd */
 action jump
 description "Handle WAN to LAN connections"
 destination {
     group {
         network-group LAN_NETWORKS
     }
 }
 inbound-interface {
     group WAN
 }
 jump-target FROM_OUTSIDE

I commented on the action command to have it within the rule, if you do it on the rule number it doesn’t display if you do a show on that specific rule. You can place a comment on any level or item of the configuration as far as I’m aware so it’s a lot more powerful in that regard.

1 Like

Thank you Korikaze, that works on a per rule basis. It doesn’t seem to work on the firewall name alone, which is where I put the “overview” of all rules in that zone pair.

comment firewall name zone1.zone2 "this is a comment"

doesn’t show up when I run:

show firewall name zone1.zone2

It does show-up if I run:

show firewall name

and scroll through to that particular zone pair.

In config.boot is shows as

/* "this is a comment */
name zone1.zone2 {
    default-action drop
....

The show firewall name zone1.zone2 command seems to display the config starting at default-action drop, which comes after the firewall name and comments as seen above, those aren’t shown.

I wonder if it’s possible for these lines to be included in the output somehow.

1 Like

That’s what I was getting at, you need to comment at the first sub-item in that hierarchy or else it doesn’t get displayed. If you did comment firewall name zone1.zone2 default-action "this is a comment" it would show up the way you want.

1 Like

I see, yes you did say that. Sorry, I’ve been jumping between tasks and didn’t read carefully. Just tested it and it does show up. Thank you!

2 Likes