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

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

Other instances:

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?

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.

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:

@Viacheslav but that sounds more of a decent FRR bug. We could still consider adding EIGRP support for 1.4

Backported fix from T3637

oh good grief this is an old problem.. Just found a reference here while researching: https://community.ui.com/questions/DHCP-Failover-Configuration-Multiple-VLAN-interfaces/da7a0f03-2c4e-4d9f-9924-c2297db177db

I can't reproduce it in 1.3-rc5

set interfaces wireguard wg0 address '10.1.0.3/24'
set interfaces wireguard wg0 address 'cafe:c01d:c01a::2/64'
set interfaces wireguard wg0 description 'VPN-to-wg-PEER01-192.0.2.1'
set interfaces wireguard wg0 ipv6 ospfv3 cost '24'
set interfaces wireguard wg0 ipv6 ospfv3 dead-interval '40'
set interfaces wireguard wg0 ipv6 ospfv3 hello-interval '10'
set interfaces wireguard wg0 ipv6 ospfv3 instance-id '0'
set interfaces wireguard wg0 ipv6 ospfv3 priority '1'
set interfaces wireguard wg0 ipv6 ospfv3 retransmit-interval '5'
set interfaces wireguard wg0 ipv6 ospfv3 transmit-delay '1'
set interfaces wireguard wg0 peer PEER01 address '192.0.2.1'
set interfaces wireguard wg0 peer PEER01 allowed-ips '0.0.0.0/0'
set interfaces wireguard wg0 peer PEER01 allowed-ips '10.0.3.0/24'
set interfaces wireguard wg0 peer PEER01 allowed-ips '::/0'
set interfaces wireguard wg0 peer PEER01 port '12345'
set interfaces wireguard wg0 peer PEER01 pubkey 'Cpqy8='
set interfaces wireguard wg0 port '54321'
set protocols ospf area 0 network '10.1.0.0/24'
set protocols ospf passive-interface 'default'
set protocols ospf passive-interface-exclude 'wg0'
set protocols ospfv3 area 0 interface 'wg0'

The issue seems still present in Vyos 1.3.0-rc5

Please backport this to 1.3. Thanks.

Thanks for the confirmation

Hi @c-po i've been testing the added command.

yes , but when you use 'set protocols static route 10.0.0.0/8 next-hop 1.1.1.1 next-hop-vrf red' it doesn't install the prefix in the default table :

@tjh If you have a test lab, can you check conntrack-sync in the latest 1.3?

@dongjunbo this is a very very basic PR for VyOS 1.4 with the goal to implement this into the main VyOS release.

https://github.com/vyos/vyos-1x/pull/908

Commands are implemented.

Thanks Chris I'll test it once available and let you know!!

Added command set service conntrack-sync interface <intrerface> port <port>

Fixed for 1.3 in commit https://github.com/vyos/vyos-1x/commit/21527ef4551613fe9b7eed9e4b2ce33ad46fe540

Fixed for 1.3 in commit https://github.com/vyos/vyos-1x/commit/21527ef4551613fe9b7eed9e4b2ce33ad46fe540 and T3535

I'm seeing the same behavior for the OSPF v2 configuration on the 1.4 train for an image built on April 26th 2021. Just a heads up.

Hi @c-po I hope you're doing great!

conntrack implementation changed form 1.3 -> 1.4 by a rewrite. Can you please tell us which version of VyOS you are using?

Looks good on 1.4-rolling-202107010537 and 1.3-beta-202106301443: