Zone based firewall command line

Is there any change in the command line for zone based firewall in the latest nightly??

[edit]
vyos@vyos# set firewall zone

  Configuration path: firewall [zone] is not valid

[edit]
vyos@vyos# set firewall zone

  Configuration path: firewall [zone] is not valid
  Set failed

1 Like

Yeah, this caught me too. It appears to be part of a general re-factoring of the firewall code – from reading the git commit messages.

I’m relatively new to VyOS (only a few weeks of trying to use it). I am wondering if this kind of “config file/command line churn” is typical for the project. On the other hand, I may just have stumbled in at the wrong time.

It’s kind of disheartening to follow the zone-based firewall approach – supported by the config-file-as-text which allows for management by git more-or-less like code – only to find the entire supporting syntax mutate away. I’m not even sure if the underlying concepts are still valid.

Clearly, the author of the code is entitled to refactor the underlying code, no quarrel on that front from me. But churning the syntax too? Maybe I simply don’t yet know where to look for warnings about this kind of stuff.

Anyway, I was just getting more comfortable with VyOS, but am now wandering around a bit lost again…

show firewall group also broken too. I wounder It’s hard install vyos 1.4 as a stable version to test.

show firewall group 

well , these types of changes are not common but this was extremely necessary to introduce all the benefits of a powerful firewall and give more granularity our user. Evidently, the learning curve can appear intricate if one remains detached from the netfilter process. Nevertheless, upon engaging with the architecture and recognizing its wealth of possibilities, that is when the journey of comprehension truly commences:

https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks

we are documented it in our documentation
https://docs.vyos.io/en/latest/configuration/firewall/general.html

Anyway , we are preparing more docs / example to our users understand the new structure and can benefit from them , it’s part of the learning process i think.

VyOS 1.3.3 LTS is the current stable version.

Whats going on now is develoment in 1.4-rolling release where a refactoring of the firewall “config engine” have been performed so its expected that things will be tested and might be broken from time to time.

There are migration scripts that runs automagically during boot when you upgrade from one version to another that should take care of the conversation of syntax between old vs new firewall config syntax.

Over at Firewall — VyOS 1.4.x (sagitta) documentation there is documenation for both old and new syntax.

With that being said I would assume having the VyOS team create a dedicated blog post about the change would be a good thing (along with examples of the changes etc).

Personally I think the new syntax is prefered however I get why the zonebased approach is liked and hopefully there will be updated documentation on how to achieve zonebased firewalling with the new syntax (or if that would return as syntax in config-mode).

When I create firewall rules I prefer to do them as zones but zones is just another way of group physical and virtual interfaces (VIF aka VLAN) - the same can be achieved using interface-groups.

For example that zone LAN might be eth0 (untagged) + eth0.1000 (tagged VLAN1000) + eth0.1001 (tagged VLAN1001). Where zone DMZ might be eth0.2000 (tagged VLAN2000).

And then the rules use “destination-if LAN” instead of having 3 separate rules (one per untagged/tagged VLAN).

I also group my rules based on destination-zone this way you protect each zone from incoming traffic.

So instead of the old zone design in VyOS where if you had 3 interfaces you would end up with:

WAN_to_LAN
WAN_to_DMZ
LAN_to_WAN
LAN_to_DMZ
DMZ_to_WAN
DMZ_to_LAN

I do:

To_WAN
To_LAN
To_DMZ
1 Like

I am in the same boat as you. Still learning VyOS and honestly want to move to it ASAP, but this kinds of unannounced major changes reduce my speed.

I am not sure what would be the new syntax for zone based firewalls now. I have always used zone based firewalling as it gives lots of flexibility.

We have seen two changes in past one year
Earlier it was set zone, then it became set firewall zone and don’t know what now.

1 Like

You can update your node where zone policy and it migrates all rules to the new syntax

That works but this definitely requires a bigger learning curve, at least for me. All the best for revised documentation. Following (partial config) is what it brings out post upgrade. The zones were north, south and local earlier.

 ipv4 {
     forward {
         filter {
             default-action accept
             rule 101 {
                 action accept
                 inbound-interface {
                     interface-group IG_north
                 }
                 outbound-interface {
                     interface-group IG_north
                 }
             }
             rule 106 {
                 action jump
                 inbound-interface {
                     interface-group IG_south
                 }
                 jump-target south-north
                 outbound-interface {
                     interface-group IG_north
                 }
             }
             rule 111 {
                 action drop
                 description "zone_north default-action"
                 outbound-interface {
                     interface-group IG_north
                 }
             }
             rule 116 {
                 action accept
                 inbound-interface {
                     interface-group IG_south
                 }
                 outbound-interface {
                     interface-group IG_south
                 }
             }
             rule 121 {
                 action jump
                 inbound-interface {
                     interface-group IG_north
                 }
                 jump-target north-south
                 outbound-interface {
                     interface-group IG_south
                 }
             }
             rule 126 {
                 action drop
                 description "zone_south default-action"
                 outbound-interface {
                     interface-group IG_south
                 }
             }
         }
     }
     input {
         filter {
             default-action accept
             rule 101 {
                 action jump
                 inbound-interface {
                     interface-group IG_north
                 }
                 jump-target north-local
             }
             rule 106 {
                 action jump
                 inbound-interface {
                     interface-group IG_south
                 }
                 jump-target south-local
             }
             rule 111 {
                 action drop
             }
         }
     }

Yeah so in your case you should create an interface-group named NORTH and one named SOUTH and act on destination to each.

And then create this for both filter INPUT, OUTPUT and FORWARD.

Stuff that goes INPUT and OUTPUT is for the firewall itself (application running within the VyOS for example dhcp-server) while FORWARD is stuff that (once accepted) VyOS will route through it.

1 Like

Thanks. Let me try this out on a greenfield setup.
I am still not sure why we did this change when things were working fine with regular zone based configurations.
Anyways, it is what it is

Yes it might be better in the long term, but for those of us running 1.4-rollling it’s now become a major learning curve to understand and begin to modify our existing fw ruleset.

The previous zb fw syntax was simple and powerful, old config was 1394 lines, now expanded to 1978 with the new syntax. I guess I’ve got some learning to do in case I need to edit things… The line of sight to my old zb based config is totally lost.

Assuming that more significant changes aren’t planned in terms of file and command syntax…?

This is the development version, so they can change anything anytime.
You want a stable syntax / api, use version 1.3 LTS.

Regarding the new firewall syntax, we all need to learn it.

1 Like

There’s no agreed financially viable route to get LTS as an individual user. I use rolling to also help contribute to development (where I can), and understand things can change any time.

This new syntax seems to have lost the valuable abstraction that was present in the “old” syntax. That was a huge value add and I didn’t necessarily need to know the underlying implementation.

edit - I know I can build my own 1.3.x based ISO.

For example, this allowed me to achieve a nice zb firewall config that was readable and clear to modify. My new config heavily implies I need to know and work with something that’s more or less a native netfilter config. Vyos’ value is in hiding this level of detail.

Let’s see how this develops.

1 Like

For me, its a massive learning curve only because there aren’t many examples (yet), I know the VyOS team have already addressed this above, but sitting here trying to figure out what is “correct” and what commands I need to use to set the config is a headache at the moment.

If there were some good examples such as “this is the old command(s), this is the new command(s)” type thing to achieve basic functions it would be much more beneficial than, well trying to guess lol.

This rewritten firewall syntax is much more powerful than before though, just lots of different terminology used to what I had gotten to know previously.

2 Likes

To me, the “jump” statements scattered throughout the newly converted syntax are a major downside.

The old zone approach – at the very least – sugared such syntax away. I’m not saying that the migrated syntax is wrong per se. I’m simply saying that it removes a useful layer of abstraction and forces me to think in something akin to assembler…

I’ll quote the title of Dijkstra’s paper [1] from 1968: “Go To Statement Considered Harmful”.

[1] Communications of the ACM 11, 3 (March 1968). 147-148.

2 Likes

+1 on this jump statements. The simplicity which zone based syntax had, is now all gone. Now it looks more complicated.
Also as @counteradditional mentioned, an old vs new tutorial would be really helpful.

2 Likes

To me its the other way around, on the other hand I have been dealing with iptables for +20 years.

Also to me zonebased firewalling is not those 6 different chains (for 3 interface-groups) which previous abstraction layer had but rather 3 different chains since you will protect what is about to enter (ingress) into a zone.

I think what’s missing is a clear line of sight from old to new. Many of us profited greatly from the abstraction provided in the old syntax, meaning we didn’t need to know iptables and netfilter. IMHO this is exactly the value Vyatta, Vyos, EdgeOS provided their users, taking away the detail via sensible and logical abstractions.

When I updated, all my firewall configuration was removed except my groups. I did not have time to deal with this so I just rolled back to my previous configuration.

Open please a bug report and attach the example of configuration which not migrates.
https://vyos.dev/