After the recent (1) firewall refactoring ([T5160](https://vyos.dev/T5160)) and (2) the re-addition of support zone-based firewall syntax ([forum mention](https://forum.vyos.io/t/the-decision-to-remove-zone-based-firewall-syntax-in-vyos-1-4-rolling-202308040557/12014/16?u=marvin)), I've found that the global state-policy that corresponded with the "old" zone syntax does not properly migrate when going from the "old" zone system to the "new" zone system.
Basically the presence of custom tables (zone-relationships) and the way they are invoked in the backend nftables post-migration prevents the entire migrated Forward/Input/Output filter state policies (see below) from ever taking effect, therefore stateful traffic filtering does Not work -- session/flow return traffic fails.
In example below, on the migrated (1.5) configuration, a ping initiated from the "northwindslan" zone to the "internet" zone will not receive ICMP responses until a rule is added to explicitly allow ESTABLISHED traffic. Eg. `firewall ipv4 name internet-northwindslan rule 1 action accept` & `firewall ipv4 name internet-northwindslan rule 1 state established`.
Suggested resolution: automatically add any global state policy rules on the "old" configuration to each custom table in the "new" configuration during the config migration process.
-------------
The problem in detail:
Working configuration: replies to pings from northwindslan to internet are received as expected.
`1.4-rolling-202306020317` containing this example configuration under firewall:
```
firewall {
name northwindslan-internet {
default-action accept
}
name northwindslan-local {
default-action accept
}
name internet-northwindslan {
default-action drop
}
name internet-local {
default-action drop
}
name local-northwindslan {
default-action accept
}
name local-internet {
default-action accept
}
state-policy {
established {
action accept
}
invalid {
action drop
}
related {
action accept
}
}
zone northwindslan {
from internet {
firewall {
name internet-northwindslan
}
}
from local {
firewall {
name local-northwindslan
}
}
interface eth5
}
zone internet {
from northwindslan {
firewall {
name northwindslan-internet
}
}
from local {
firewall {
name local-internet
}
}
interface eth4
}
zone local {
from northwindslan {
firewall {
name northwindslan-local
}
}
from internet {
firewall {
name internet-local
}
}
local-zone
}
}
```
Then install:
`1.5-rolling-202311220024` which runs migration scripts to the latest implementation of the firewall that accommodates zones.
Failing condition: with the config below, pings initiated from the northwindslan zone to the internet zone are Not recieved (until one adds a rule accepting ESTABLISHED traffic under `internet-northwindslan`).
Auto-Migrated configuration:
```
firewall {
ipv4 {
forward {
filter {
default-action "accept"
rule 1 {
action "accept"
state "established"
}
rule 2 {
action "drop"
state "invalid"
}
rule 3 {
action "accept"
state "related"
}
}
}
input {
filter {
default-action "accept"
rule 1 {
action "accept"
state "established"
}
rule 2 {
action "drop"
state "invalid"
}
rule 3 {
action "accept"
state "related"
}
}
}
name eastwoodtc-internet {
default-action "accept"
rule 1 {
action "accept"
state "established"
}
}
name eastwoodtc-local {
default-action "accept"
}
name internet-eastwoodtc {
default-action "drop"
rule 1 {
action "accept"
state "established"
}
}
name internet-local {
default-action "drop"
}
name local-eastwoodtc {
default-action "accept"
}
name local-internet {
default-action "accept"
}
output {
filter {
default-action "accept"
rule 1 {
action "accept"
state "established"
}
rule 2 {
action "drop"
state "invalid"
}
rule 3 {
action "accept"
state "related"
}
}
}
}
```