Fixed in https://github.com/vyos/vyos-1x/pull/2342

I wonder if we need the ASCII art though or not the plain fingerprints only (first line of the command)

Implementation complete

Implementation complete

Implementation complete

Implementation complete

Implementation complete

Implementation complete

Implementation complete

OpenVPN cannot pass the smoketest

 DEBUG - ======================================================================
DEBUG - FAIL: test_openvpn_options (__main__.TestInterfacesOpenVPN.test_openvpn_options)
DEBUG - ----------------------------------------------------------------------
DEBUG - Traceback (most recent call last):
DEBUG -   File "/usr/libexec/vyos/tests/smoke/cli/test_interfaces_openvpn.py", line 525, in test_openvpn_options
DEBUG -     self.assertNotEqual(cur_pid, new_pid)
DEBUG - AssertionError: None == None
DEBUG - 
DEBUG - ======================================================================
DEBUG - FAIL: test_openvpn_site2site_interfaces_tun (__main__.TestInterfacesOpenVPN.test_openvpn_site2site_interfaces_tun)
DEBUG - ----------------------------------------------------------------------
DEBUG - Traceback (most recent call last):
DEBUG -   File "/usr/libexec/vyos/tests/smoke/cli/test_interfaces_openvpn.py", line 601, in test_openvpn_site2site_interfaces_tun
DEBUG -     self.assertTrue(process_named_running(PROCESS_NAME))
DEBUG - AssertionError: None is not true

I had a similar issue going from 1.5-rolling-202309250022 to 1.5-rolling-202310090023.

Then this task can be set to closed and invalid :-)

PR updated: https://github.com/vyos/vyos-build/pull/435

If you don't use the firewall (statefully at least) then it will go through the FW_CONNTRACK chain and the NAT_CONNTRACK and/or WLB_CONNTRACK chains will be reached, or fall through to the notrack.

But the NAT_CONNTRACK and WLB_CONNTRACK chains are never evaluted because FW_CONNTRACK always set action to accept?

PR: https://github.com/vyos/vyos-1x/pull/2361

This should fix the problem: https://github.com/vyos/vyos-1x/pull/2361

That is how the conntrack enabling system works. FW_CONNTRACK verdict is set to accept when it is determined the firewall needs conntracking (state rules, flowtable etc.), same for NAT_/WLB_ chains. If none require conntrack - all chains will be return and it falls down the chain to the final notrack and conntrack is not enabled.

An additional "nice to have" would be a hook that runs on route state change.
Examples:

set protocols failover route 0.0.0.0/0 next-hop 100.100.100.1 hook '/config/scripts/failover-hook-100.100.100.1'

PR: https://github.com/vyos/vyos-1x/pull/2357

PR: https://github.com/vyos/vyos-1x/pull/2355

show conntrack statistics shows only sudo conntrack -S command
This won't show any logs

In T5497#161764, @Apachez wrote:

I assume this will end up in config mode aswell before this task can be set to resolved?

Simply because this is a few more steps:

• Use the command
• Copy the output
• Delete current firewall
• Paste command output
• Commit

than this:

• Use the command
• Commit

I assume this will end up in config mode aswell before this task can be set to resolved?

Once PR https://github.com/vyos/vyos-1x/pull/2344 is merged, counters and logs for default action should be available once again.

It's an op-mode command, so it does not changes configuration. User may get something different from what he expected, so at least on this very first attempt of re-generating and re-ordering firewall rules, it's done in op-mode command with no impact on running configuration.

The syntax seems to have changed from "produce" to "generate" during this task?