proto-overwrite isn't working

[openvpn]

proto-overwrite isn't working

[OriBenHur]

the ticket on openvpn-as is for the 9 udp entries.
the overwrite not working is here.
just to make things bit more clear.
after removing all the extra udp entries the override is working as expected.
with the extra udp entries it's not working (still connecting with udp instead of using tcp)

[dsommers]

Could you provide the --remote options in your configuration file? If you only have a single --remote line, try duplicating it and set the second line to be tcp. For example like this:

remote server.example.net 1194 udp
remote server.example.net 443 tcp

See if the --proto-override makes a difference with such a config, and if it then sticks to the overridden protocol through several connections and also openvpn3 session-manage --restart. You may also need to see if --port-override also works as expected.

If the multiple --remote line works, it is needed to investigate this issue in the OpenVPN 3 Core library project.

[dsommers]

ping, @OriBenHur ... did you get a chance to test this?

[OriBenHur]

i have 6 of them all but one are udp
this is the file that the as server created

[OriBenHur]

# Automatically generated OpenVPN client config file
# Generated on Mon Sep 14 01:23:41 2020 by OpenVPN-AS

# Default Cipher
cipher AES-256-CBC
# Note: this config file contains inline private keys
#       and therefore should be kept confidential!
# Note: this configuration is user-locked to the username below
# OVPN_ACCESS_SERVER_USERNAME=<USERNAME>
# Define the profile name of this particular configuration file
# OVPN_ACCESS_SERVER_PROFILE=<USERNAME>@<IP>
# OVPN_ACCESS_SERVER_CLI_PREF_ALLOW_WEB_IMPORT=True
# OVPN_ACCESS_SERVER_CLI_PREF_BASIC_CLIENT=False
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_CONNECT=False
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_XD_PROXY=True
# OVPN_ACCESS_SERVER_WSHOST=<IP>:<TCP_PORT>
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_START
# -----BEGIN CERTIFICATE-----
# <HASH>
# -----END CERTIFICATE-----
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_STOP
# OVPN_ACCESS_SERVER_IS_OPENVPN_WEB_CA=1
setenv FORWARD_COMPATIBLE 1
client
server-poll-timeout 4
nobind
remote <IP> <UDP_PORT> udp
remote <IP> <UDP_PORT> udp
remote <IP> <TCP_PORT> tcp
remote <IP> <UDP_PORT> udp
remote <IP> <UDP_PORT> udp
remote <IP> <UDP_PORT> udp
remote <IP> <UDP_PORT> udp
remote <IP> <UDP_PORT> udp
dev tun
dev-type tun
ns-cert-type server
setenv opt tls-version-min 1.0 or-highest
reneg-sec 604800
sndbuf 0
rcvbuf 0
auth-user-pass
static-challenge "Enter Authenticator Code" 1
# NOTE: LZO commands are pushed by the Access Server at connect time.
# NOTE: The below line doesn't disable LZO.
comp-lzo no
verb 3
setenv PUSH_PEER_INFO

<ca>
-----BEGIN CERTIFICATE-----
<HASH>
-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----
<HASH>
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----
<HASH>
-----END PRIVATE KEY-----
</key>

key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key (Server Agent)
#
-----BEGIN OpenVPN Static key V1-----
<LONG_NUMBER>
-----END OpenVPN Static key V1-----
</tls-auth>

## -----BEGIN RSA SIGNATURE-----
## <HAS-5>
## -----END RSA SIGNATURE-----
## -----BEGIN CERTIFICATE-----
## <HASH>
## -----END CERTIFICATE-----
## -----BEGIN CERTIFICATE-----
## <HASH>
## -----END CERTIFICATE-----

[schwabe]

Well if you force the core to only use tcp remotes but have no tcp remotes that is not going to work. So the core ignores your request

[OriBenHur]

but there is one lol
as you can see there are like 9 UDP and one TCP, I have no idea why (I'll open a bug for the OpenVPN-AS team about it)
but in theory, it should work, BTW removing all the extra UDP seems to be working the question is why is;t it working with them there?

[schwabe]

Hm sorry, I didn't see that TCP one. No idea then, sorry

[dsommers]

but there is one lol
as you can see there are like 9 UDP and one TCP, I have no idea why (I'll open a bug for the OpenVPN-AS team about it)
but in theory, it should work, BTW removing all the extra UDP seems to be working the question is why is;t it working with them there?

I'm a bit confused now, since you're pulling in filing an AS ticket as well.

When you use openvpn3 config-manage --config <NAME> --proto-override tcp, does it still try UDP? If yes, then this is an OpenVPN 3 issue; but can tackle that in this ticket for now.

If the AS server does not provide a functional TCP port, that's a different issue where an AS ticket is appropriate.

[schwabe]

@dsommers I think he is referring to having 9 identical UDP remotes at all.

[dsommers]

Okay, that's 2 independent bugs then. I'll create an internal ticket for the protoOverride not working with multiple identical remotes configured. I'll leave this ticket open until the OpenVPN 3 Core library has been updated and OpenVPN 3 Linux has upgraded to that version.

[schwabe]

@dsommers to be honest, we might remove these override features. I have no idea what real use case they have anyway.

[OriBenHur]

i can tall you from my experience that they give me an easy way to switch back and forth tcp and udp on a need basis.
but it's not like it's that difficult to create two profiles to serve each.
but my moto is if it's there it need to work

[dsommers]

I think the the server, port and proto overrides makes sense. And I'm even considering if we should add support for this even via openvpn3 session-start. But there are other overrides which might be less useful.

[dsommers]

We're just releasing the v14_beta today. Can you see if the protocol override using openvpn3 config-manage --config <NAME> --proto-override tcp works with this release?

In addition I'm strongly considering to add --proto-override (or a similar option) to openvpn3 session-start as well, similar to what we now support with --dco.

[dsommers]

The configuration profile need to have a remote line for both TCP and UDP for the --proto-override feature to work. That does work, but only on non-persistent configuration files. There is a bug in the code saving the persistent configuration files to disk, so if multiple --remote options are present, only the last occurrence is present.

I will close this ticket, as --proto-ovrerride itself works as expected. But there is a different issue making this not working, which is not really a problem of --proto-override at all. This other issue will be tracked in a separate ticket.