This is already available in VyOS 1.4

@Scoopta, thank you. That's good. I *think* know how the logic should go. Shouldn't be difficult but I'll consult with @Viacheslav and @c-po on how we should tackle it. It shouldn't be hard, but I want to make sure I properly do it :)

@Viacheslav, @c-po, the ISIS FRR Jinja2 template is significantly different between 1.3 and 1.4. Should I try to make the change on 1.3 and then merge? Or should I make it on 1.4 and we'll find a way to merge it back into 1.3?

@Cheeze_It Yes, I actually patched my version of vyos already. Just have to add

ipv6 router isis {{ process }}

to the frr isis template file

PKI Wireguard PR: https://github.com/vyos/vyos-1x/pull/929

@Viacheslav, @Scoopta, I take it for default originate on IPv6 there's a requirement to have "ipv6 router isis" added on the interface? I'm thinking yes. If it's a yes (which I'm thinking it is) then I believe this should be fairly easy to add. I'll give it a check guys.

@Scoopta Provide please example of configuration with every task.
If it a possible example of frr, for what you get and what you expected.

thanks for your comment , we are testing first with @rherold , I understand that your case is similar but it's not the same (you have an explicit route-leaking between default vrf and vrf X ). So we also need to test it and try to sure the version solved it .

PR for 1.3 https://github.com/vyos/vyatta-cfg-quagga/pull/84

@zsdc
please take a look on this
it might be some similar issue in this patch?
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=0fb4d21956f4a9af225594a46857ccf29bd747bc

Can you send more examples how it looks like in podman cli?
Which parameters do you set, and how to check if it is successfully applied?

Can you please try running this test on a more recent VyOS version?

I have made a second attempt of the PR: https://github.com/vyos/vyos-1x/pull/928
The original tls configuration checks are back, but it's only checked if no alternative authentication methods are configured.

brctl is a deprecated package and superseeded by iproute2. Commands will be adjusted, thanks for reporting.

As I suspected, it check if the ConfigSession properly errors if "tls cert-file" and "tls key-file" are NOT defined (for server):

something like this in 1.4 nft
https://www.spinics.net/lists/netfilter/msg58240.html

It seems 1.4-rolling has this bug also
i setup vrf wg with all wireguard clients (with private ip)
and setup vrf leak to vrf default
NAT didn't work on it.
it will send un-NAT packet to eth0

You can find the test here: https://github.com/vyos/vyos-1x/blob/current/smoketest/scripts/cli/test_interfaces_openvpn.py

Hmm. Can you point me to the smoketest that failed? I will investigate. Maybe it actually tests if the strict check are in place, because now cert-file and key-file are optional, but it should keep working if you configure it.

Unfortunately I had to revert this PR as it broke the smoketests and also triggered the following OpenVPN error:

I'm not sure, I haven't tried it. Thing is if I add

set interfaces openvpn vtun2 local-address fe80::1

In T3686#98142, @Scoopta wrote:

My config which breaks

set interfaces openvpn vtun2 device-type tap
set interfaces openvpn vtun2 mode site-to-site

My config which breaks

For first we have to solve this bug T3689

In my test configuration all works fine.

set interfaces bridge br0 address '10.0.0.1/30'
set interfaces bridge br0 member interface vtun0
set interfaces openvpn vtun0 device-type 'tap'
set interfaces openvpn vtun0 encryption cipher 'aes128'
set interfaces openvpn vtun0 mode 'server'
set interfaces openvpn vtun0 server subnet '192.168.1.0/24'
set interfaces openvpn vtun0 tls ca-cert-file '/config/auth/openvpn/ca.crt'
set interfaces openvpn vtun0 tls cert-file '/config/auth/openvpn/central.crt'
set interfaces openvpn vtun0 tls dh-file '/config/auth/openvpn/dh.pem'
set interfaces openvpn vtun0 tls key-file '/config/auth/openvpn/central.key'

It looks like was the same bug T1866
Try ssh keyscan
https://docs.vyos.io/en/latest/cli.html#remote-archive

Have tried 1.3.0-rc5, the issue remains.

@Scoopta Can you share commands on how to reproduce it?
It will be easier for developers to reproduce this bug.