Route: Waiting for TUN / TAP interface to come up ...

[lozhkinalexey]

Greetings.
I observe the following problem when connecting to OpenVPN 2.4.9-I601-win10:
If on the local interface the gateway address is on a different subnet, then when I try to connect to OpenVPN, I get the following:
TEST ROUTES: 18/38 succeeded len = 38 ret = 0 a = 0 u / d = up
Route: Waiting for TUN / TAP interface to come up ...

If you enable more detailed logging (verb 7), then the log contains the following lines with the addition of routes with a negative index and a large metric:
Fri Jul 10 13:31:09 2020 us = 361160 DEBUG: IP Locate: ip = 192.168.1.1 nm = 0.0.0.0 index = -1 count = 0 metric = 2147483647

I understand that the problem is the lack of the correct route, but I saw similar connection configurations at airports and the metro.

ipconfig:
IPv4-адрес. . . . . . . : 192.168.1.200
Netmask . . . . . . . . : 255.255.255.128
Gateway. . . . . . . . . : 192.168.1.1
DNS. . . . . . . . . . . : 8.8.8.8

[lozhkinalexey]

There is no such problem if you run OpenVPN with the same configuration on android

[tct]

Could you please add your client log at --verb 4 (Remove private data)

[lozhkinalexey]

log verb 4

[Gert Döring]

A network where the gateway is not part of the subnet is just broken - that it seems to work on windows is amazing, and could be considered a bug (if it breaks right away, people would not deploy such a config).

[lozhkinalexey]

This connection configuration is often found in cafes, subways, airports.
Gateway is located using the proxy arp.
And OpenVPN on android works with this configuration.
​https://community.cisco.com/t5/switching/defaulut-gw-is-set-as-a-different-subnet-but-it-works-why/td-p/2537423

[Gert Döring]

A machine should never send out an ARP request for something which is not inside the assigned IPv4 subnet (or something which is explicitly configured as "connected to LAN interface").

So yes, *if* the ARP is sent, Proxy ARP will make it work, but *that* it is sent is buggy behaviour on the client side in the first place, and networks relying on this behaviour are broken.

We'll have to look into default gateway lookup for 2.6 anyway, so it's possible this problem disappears in the process.

[Gert Döring]

It turns out that 2.6 focuses more on DCO (in-kernel data channel) and the associated performance benefits, and on TLS improvements. The whole "routing layer refactoring" didn't happen, but needs to.

Bumping to 2.7