Furher to this, manually setting "mru 1500" gives me my 1500 MTU back again.

The new MRU config in 1.3.4 seems to have caused my MTU to be lower.

RNDIS is once more on the "removal" list of the Linux Kernel.
https://www.phoronix.com/news/Linux-Disabling-RNDIS-Drivers

PR for current: https://github.com/vyos/vyos-1x/pull/2373

It seems related https://vyos.dev/T5663

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

Fixed in
1.4/1.5: https://github.com/vyos/vyos-cloud-init/commit/5d3e4e79746772d80a6289f352e3606382f73eaa
1.3: https://github.com/vyos/vyos-cloud-init/commit/f627bf85746c5785836086538879e1101b6c4af3

Good point @Viacheslav apologies I was distracted at the time.
I can make it work by starting manually ( # ip vrf exec RCS3 zabbix_agent2 -c /run/zabbix/zabbix-agent2.conf )so I guess updating the systemd units file (/lib/systemd/system/zabbix-agent2.service) should make this work.

In T5657#162236, @bbabich wrote:

Yep looks fine @Viacheslav
I've been using it like this for a while now but figure it may be useful as part of making 'VRFs' complete...

$ sudo ip vrf exec RCS3 mtr 192.168.222.11

Yep looks fine @Viacheslav
I've been using it like this for a while now but figure it may be useful as part of making 'VRFs' complete...

@fsbof This change was accepted so it should end up in the 1.5 rolling soon. I suspect backporting to 1.4 wouldn't be an issue but that is a question for a more senior dev. But as for 1.3, I am unsure as I have never ran that version and don't know if there are any changes between those releases that would make it a pain to backport.

In this case we can use the next solution:

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

Still fails:

Looks like this issue may actually be resolved now.

cf. T5027: the commit for this task necessarily removed the fix there, leading to failing of the same two tests. A fix is to specify a specific encryption cipher within test_openvpn_options and test_openvpn_site2site_interfaces_tun to avoid openvpn defaulting to bf.

I was also affected by this issue. I could only update to 1.5-rolling-202309280022. Updates to more recent versions had the effect that after login I coudn't manage VyOS as I only had a standard linux bash.

Did you test it in vrf? Is it really works as expected?

@JeffWDH I am happy to download, build and test when you're ready if you point me to the right version(s)/location(s). I'm also very new to this but I managed to Build Equuleus in a docker container which has been working ok. Appreciate your efforts.

I've updated this to default to no ASCII art as I think it's cleaner, but added an option to show it if you want to see it:

Wow - you guys work quickly! 👍

I think it should be included, its often used during generation in Debian among other distros.

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.

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

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

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

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

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?

Updated scan performed on VyOS 1.5-rolling-202310090023 (see attached file).

show conntrack statistics still fails in VyOS 1.5-rolling-202310090023: