Fix proxy with multiple connections on OpenVPN 3

[ValdikSS]

If several connections are configured in "Server List" tab, and only one of them has proxy, all connections will try to use proxy due to bug in configuration builder.

Add proxy directive only for a connection with proxy configured.

[schwabe]

I fixed this differently (9857821). I rather error out than to do something that is different than the config/user wants. Otherwise the next person is surprised that the app does something different than what the config specifies.

[ValdikSS]

@schwabe why though? My PR fixes it as it is in OpenVPN 2, i.e. you can have different proxies in different remotes. It just builds the configuration with one remote, and if it fails, rebuilds with another remote.
I actively use it in this configuration. It works great.

[schwabe]

@ValdikSS different philosophy. If a configuration (different proxies) per remote is unsupported with OpenVPN 3 then it is just unsupported. The app should not just do something "random" instead. This might work well for your special use case but is in my opinion not a great design.

Also OpenVPN3 is more an optional feature that is not fully featured anyway. The focus of the app is OpenVPN 2.x.

[ValdikSS]

You think of it as a phisosophy, I see it just as a deficiency of the library, and it's quite trivial for the application to overcome it.

I have a VPN server which is frequently unreachable without additional proxy, that's why I have a single connection with two remotes: one without the proxy and one with the proxy.
With my patch, the application "falls back" to the second remote after the timeout, just as it works with OpenVPN 2. With your approach, I won't be able to use that.

I use OpenVPN 3 because OpenVPN 2 handling in the app has a bug related to network switch or something like that, which could be fixed only by force-stop. This bug is hard to reproduce and it happens only in inconvenient times when I'm about to leave the house or I'm not near the computer. That's why for now I'm using OpenVPN 3.

[schwabe]

Yes. But if OpenVPN3 is not supporting this scenario then neither is my app. Your approach generates a config that is different from the configuration that user intended. If you want support for that ocnfiguration, there needs to be a n upstream fix in OpenVPN 3.

And for the OpenVPN 2.x bug. It would be good to have at least some screenshot or logs about it. Otherwise that log will be there forever.

[ValdikSS]

And for the OpenVPN 2.x bug. It would be good to have at least some screenshot or logs about it. Otherwise that log will be there forever.

Well, there isn't. The connection handling just hangs forever, without any log entries whatsoever. The current connection can't be torn down and no new connections could be established. I guess there might be race condition between terminating openvpn and starting a new instance, and two openvpns are running at the same time when this happens.

When this happens, the UI is quite laggy, and nothing in the log. It never recovers by itself. I don't have reliable reproducer, can only guess.

Just made a bug: #1924

[ValdikSS]

Your approach generates a config that is different from the configuration that user intended.

If I make a toggable option for the app, will it have a chance to get merged?

[schwabe]

I really do not get your use-case. With OpenVPN 3.x you can only have the proxy for all remotes or for no remote. The new version enforces that now.

If you want that behaviour just setup your configuration like that.

[ValdikSS]

I want auto-reconnection. I don't want to manually choose between different configurations when the connection without proxy stops working.

I have a single VPN server (single IP address) which is reachable over the Wi-Fi directly, but over cellular only via proxy. I have two remotes (two "server list" entries inside a single profile) pointing to that VPN server: a regular one with the direct connection, and the same remote with proxy configuration.

When I leave the house, I want it to automatically connect via proxy. With my patch, when the Wi-Fi is lost, it tries to reconnect over the same direct connection, fails with the timeout of 10 seconds, and tries the "remote with proxy", which works.

The proxy connection is slower and adds more latency, that's why I don't use it on Wi-Fi.
My patch forces the configuration to be built with a single remote (canUsePlainRemotes), but logically in the app there are several. When timeout occurs, the configuration is rebuilt with another remote. The application itself handles multiple remotes which are incompatible inside openvpn3 library, and does not use <connection> blocks.

If I understand your patch correctly, it will just error out for my case.

[schwabe]

When timeout occurs, the configuration is rebuilt with another remote.

I have no idea how that would work. You are describing a configuration that does not work with OpenVPN 3.x. I have not fully read your patch but I struggle to see how it can generate a configuration that achieves something that OpenVPN 3.x does not support.

Also the app has a no logic to rebuild the config and then try a different configuration in case of a failed connection, so doing different configs for different retries should also not work.

[ValdikSS]

Ok,

What do I have:

• Single OpenVPN profile
• Two server list entries: one with proxy=none, the other one with proxy=http

How it works with OpenVPN v2:

• OpenVPN for Android builds OpenVPN configuration with two <connection> blocks: one with proxy, another without proxy
• OpenVPN v2 itself handles switching between <connection> remotes when disconnection or timeout occurs, etc

How it works with OpenVPN v3, my patch:

• OpenVPN for Android treats OpenVPN v3 like it doesn't support <connection> blocks, builds OpenVPN configuration with just single remote. The first one in "server list" upon connection.
• If the connection fails (e.g. due to timeout), OpenVPN v3 terminates, the control gets back to the OpenVPN for Android. It understands what's going on, builds another OpenVPN configuration with the second remote in the "server list", starts OpenVPN v3 again.

It logically implements the same feature which OpenVPN v3 is missing, the same way it works in OpenVPN v2 (inside OpenVPN v2), but inside the application.
I'm just reusing the existing canUsePlainRemotes feature which the application already have for this. I guess it was initially created for the old OpenVPN v2 (2.3.x era?), when <connection> block did not exist yet.

How it works with your patch:

• The configuration does not go though validation, and fails (I assume, I haven't tested it, just skim though the code. Is that correct? Maybe I'm arguing for no reason?)

My point is: why follow OpenVPN v3 artificial limitation (I'm pretty sure nobody just had time to implement proxies in <connection> blocks, and this is not a deliberate decision), when you can just overcome this limitation inside the application with the existing infrastructure it already has?

[ValdikSS]

Sorry, please disregard everything I told. I'm completely wrong, it does not reconnect over proxy.

My mind is playing tricks on me. I was completely sure that I somehow fixed it in one of the PRs, but no, apparently I've just fixed the enable/disable switch in this PR, that's all. And probably all this time I tested the proxy by enabling/disabling the first server list entry, that's why I was sure that it will work the same way upon reconnection.

Took your time for nothing :/

[schwabe]

terminates, the control gets back to the OpenVPN for Android. It understands what's going on, builds another OpenVPN configuration with the second remote in the "server list", starts OpenVPN v3 again.

That is nothing that is currently implement nor does your patch implement that. You might have that in some of your local patches but this PR does not add this logic.

My point is: why follow OpenVPN v3 artificial limitation (I'm pretty sure nobody just had time to implement proxies in blocks, and this is not a deliberate decision), when you can just overcome this limitation inside the application with the existing infrastructure it already has?

Because I don't want all the complexity for this in my app of an, especially when OpenVPN 3.x is not even the main target of my app. If I were to fix this behaviour it would be as an OpenVPN 3.x patch rather than such a clunky workaround. But currently I have don't have a high priority in fixing OpenVPN 3 things.

[schwabe]

@ValdikSS no worries, happens to everyone.

Currently the best workaround is to probably have two config. One with and one without the proxy.