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.

I can't reproduce it.
Re-open the task if you get this issue again.

@jingyun Can you describe more details?

PR for 1.3 https://github.com/vyos/vyos-1x/pull/925
PR for 1.4 https://github.com/vyos/vyos-1x/pull/926

I submitted a PR for review: https://github.com/vyos/vyos-1x/pull/923

It's funny, I remember that dhcp was already removed from ether-resume.py. I checked the git history, and it was.
Related issue and discussion about netplug vs ether-resume dhclient (buried deep in the beginning) https://phabricator.vyos.net/T1028

note: Record the process of upgrading from 1.4-rolling-202107010537 to 1.4-rolling-202107122017

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

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

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

Thanks @jestabro this seems like a good place to start learning VyOS internals, will give it a go when I have some off time and submit a pull request.

@artooro This sounds reasonable, and I don't imagine a problem, though I have yet to try it; if you would like to submit a pull request with fix, I will review.

Most likely related to T3505

This error occurs because the ipsec module blindly updates the l2tp module after a commit change to ensure any l2tp via ipsec config is then refreshed also.

Workaround for missing DHCP default route:

Parent task: https://phabricator.vyos.net/T2816

Other instances:

More details https://github.com/vyos/vyatta-webproxy/pull/17

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

thanks for your detailed bisection of this issue. You mind submitting a GitHub PullRequest as per https://docs.vyos.io/en/equuleus/contributing/development.html?

@trystan Can you download this pkg to vyos /tmp and install it? It should fix this issue

The workaround stopped working after the OpenVPN configuration checks moved from Perl to Python. As this still applies to VyOS 1.3 this issue should be reopened, I can also create a new issue if that is preferred.

@sdev It still shows the ikev2 as the default version in the output.
I agree with your point that strongswan has changed the default version. A quote from their documentation: "Since 5.0.0 both protocols are handled by Charon and connections marked with ike will use IKEv2 when initiating, but accept any protocol version when responding."

good lab, thanks for your time! I want to leave a comment , I used the syntax that you recommend and it worked well ( VyOS 1.3.0-rc5):

I did a short lab test using the following topology based on my assumptions what you wan't to do using VyOS 1.3.0-rc5: