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:

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