Connection priority in case of dualstack

[joanandk]

Hi,
We have several daemons listening on UDP4+6 and TCP4+6 on the server side. A simple loadbalancer distributes connection in a round robin manner for UDP and TCP. The UDP and TCP counters are independant of each other.

On the client we have two entries, one for udp and the second one for tcp.
remote <SERVER_NAME> 1194 udp
remote <SERVER_NAME> 443 tcp

If a server daemon is full (max-clients), the server makes entries of

MULTI: new incoming connection would exceed maximum number of clients

of about 40 times before the client tries the second entry. If I understood correctly, the clients waits because of already established tls connection
and does not terminate the session until the connect-timeout has been reached?

Is there any possibility/configuration on the client side to try the second entry in such case, without waiting for the timeout? According to the manual, there should be an AUTH_FAILED message to the client?

If it is not possible to react to the message, is it possible to configure the client to try UDPv6 -> TCPv6 instead of UDPv6->UDPv4->TCPv6?
The configuration should not break in case it is used on IPv4 only network (so using remote <SERVER_NAME> 1194 udp6 is not an option).

Thanks and BR

[schwabe]

no max-clients prohibits new client connections very early. Sending AUTH_FAILED still needs a client connection slot. If you want the behaviour that you are looking for, you will need have a custom plugin/script/management interface to send the clients an AUTH_FAILED,TEMP with the correct arguments to send them to the next remote.

[joanandk]

@schwabe: Thanks for your quick response. I am unsure how to have a secure connection to the management interface of the client in such early state.

I have seen that setting keepalive 4 20 in the client config would try UDPv6 for 20s before falling to UDPv4 for 20s and getting connected via TCPv6. But according to cliopt.hpp the keepalive should be ignored?