@joolli Re-check please it in any Linux system with the option "-I "
Is it different?

ping -I dum0 10.0.12.40

Works perfect in VyOS 1.4-rolling-202104260417

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

sa_data wrong format

vyos@r6-roll:~$ show vpn ipsec sa
[[b'peer-203.0.113.2-tunnel-vti',
  'up',
  '4m33s',
  '168B/168B',
  '2/2',
  '203.0.113.2',
  'N/A',
  'AES_CBC_256/HMAC_SHA1_96/MODP_1024'],
 ['peer-192.0.2.2-tunnel-vti',
  'down',
  'N/A',
  'N/A',
  'N/A',
  'N/A',
  'N/A',
  'N/A']]
Connection                      State    Uptime    Bytes In/Out    Packets In/Out    Remote address    Remote ID    Proposal
------------------------------  -------  --------  --------------  ----------------  ----------------  -----------  ----------------------------------
b'peer-203.0.113.2-tunnel-vti'  up       4m33s     168B/168B       2/2               203.0.113.2       N/A          AES_CBC_256/HMAC_SHA1_96/MODP_1024
peer-192.0.2.2-tunnel-vti       down     N/A       N/A             N/A               N/A               N/A          N/A
vyos@r6-roll:~$

This bug is still present in VyOS 1.4-rolling-202104061143.

https://github.com/containernetworking/plugins/issues/461

To reproduce the bug, we need to add a source nat rule first.

configure
set nat source rule 100 outbound-interface 'eth0'
set nat source rule 100 source address '192.168.0.0/24'
set nat source rule 100 translation address masquerade
commit
save
exit

Then if we try to list the nat tables with iptables iptables -t nat -L, we will get error like table 'nat' is incompatible, use 'nft' tool.
Next, if we use podman to create a container sudo podman run -d ubuntu:latest, podman will return the error because it will look up nat rules with iptables.

Work as expected on 1.4-rolling-202104260417

vyos@R1:~$ show dhcpv6 server leases 
IPv6 address        State    Last communication    Lease expiration     Remaining    Type               Pool         IAID_DUID
------------------  -------  --------------------  -------------------  -----------  -----------------  -----------  -----------------------------------------------------
2001:db8:290::/64   active   2021/04/23 14:52:48                                     prefix delegation  VyOS-DHCPv6  00:00:00:00:00:01:00:01:28:15:9b:bd:50:00:00:06:00:00
2001:db8:3456::15b  active   2021/04/27 05:07:51   2021/04/27 17:07:51  10:28:27     non-temporary      VyOS-DHCPv6  00:00:00:00:00:01:00:01:28:15:9b:bd:50:00:00:06:00:00

Fixed in

@Yuanandyuan Can you reproduce it with vyos cli? Or it raw podman commands?

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

Retested this with VyOS 1.3.0-rc3 and the bahavior is the same.

Turns out the example config has a typo. Issue is reproducible by:

Analysing the provided configuration file has shown that this is unrelated to the change. The supplied configuration used a non existing route-map/prefix list on the CLI. As this is now properly validated for existence the error was triggered.

How were you be able to set this on the CLI?

https://github.com/vyos/vyos-documentation/commit/d24b81bed22231d6efc561604809e3dacf2aa0e5

Looks good on 1.3-rolling-202104220921:

Looks good on 1.3-rolling-202104220921 (including migration from 1.2.7).

Discussed on slack channel (#lobby) with @christian Poessinger. He has the relevant original configuration file in PM.

https://github.com/vyos/vyos-build/pull/162

This is a bug which is introduced by the rewrite of policy from old node.def files to XML and Python.

Moved to misc as requested https://github.com/vyos/vyos-utils-misc/pull/1

That was generated by running make defconfig, enabling numa, and saving it back. BUILD_BIN2C is related to kexec.

Additionally, I've discovered that CURL uses libssh2 which doesn't support newer host keys (e.g. current default ed25519). Most hosts generate an RSA key as well, but using ssh to log into the remote host will, by default, only place the ed25519 host key in the authorized keys file. The following command: