https://github.com/vyos/vyos-utils/pull/28

https://github.com/vyos/vyos-1x/pull/4234
Development has begun! :)

I’ve been using it as is since I posted this, it’s been working fantastically

the PR to fix this is https://github.com/vyos/vyos.vyos/pull/367

The PR tp fix this https://github.com/vyos/vyos.vyos/pull/367

hi,I am interested in this issue and would like to work on it.
If there are any relevant code references or examples, please let me know.

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

Any update about this feature?

This looks promising:

Connected Since
------------ 
 2024-12-09 18:36:18

Per TimH in slack:

https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/
--auth-gen-token [lifetime]
After successful user/password authentication, the OpenVPN server will with this option generate a temporary authentication token and push that to client. On the following renegotiations, the OpenVPN client will pass this token instead of the users password. On the server side the server will do the token authentication internally and it will NOT do any additional authentications against configured external user/password authentication mechanisms.The lifetime argument defines how long the generated token is valid. The lifetime is defined in seconds. If lifetime is not set or it is set to 0, the token will never expire.This feature is useful for environments which is configured to use One Time Passwords (OTP) as part of the user/password authentications and that authentication mechanism does not implement any auth-token support.
OpenVPNOpenVPN
Reference Manual For OpenVPN 2.4 | OpenVPN
Because OpenVPN tries to be a universal VPN tool offering a great deal of flexibility, there are a lot of options on this reference page for OpenVPN 2.4

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

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

In T4930#209720, @runar wrote:

Routgh idea:

If peer is created with hostname over IP, do not add it during commit

I would insist only not adding endpoint, let peer be ready if they have configured with hostname endpoint.

The peer should be pre-provisioned with everything needed to be accessible externally for a remote peer to reconnect prior to dns resolution.
To allow for this the peer can be added with a endpoint of 0.0.0.0. (if a wireguard peer is not able to be provisioned without a endpoint at least)
This can then be used to "abort" a DNS resolution if the remote end has reconnected.
Only the "resolve dns" part should then be the blocking part, and only that part needs to be moved out of the commit loop.

Routgh idea:

If peer is created with hostname over IP, do not add it during commit

I would insist only not adding endpoint, let peer be ready if they have configured with hostname endpoint.