I've been operating a small OpenVPN Access Server on a Linux box for ages. I recall starting with OpenVPN 2.0.9-ish, now the server is at about 2.4.
Today I've come to ask for help with a recent issue on the OpenVPN client side.
We're trying to install OpenVPN on a shiny new PC, running Windows 11, installed from a fresh upstream Microsoft image.
We have previous setups in Win11 that are reported to work...
Versions:
Windows 11 22H2 build 22621.1848 (released 20230613 = the latest release)
OpenVPN community edition 2.6.5 (also tried 2.6.4)
TAP/Windows6 v9.26.0 (freshmost, comes with OpenVPN 2.6.5)
In the client's log window (in the OpenVPN GUI), towards the end of the connection process, I can see several red messages saying "route gateway is not reachable". I've tried some ancient remedies (setting "run as administrator" to all the EXE binaries
and tried disabling+enabling the TAP interface, to no avail. I haven't found a recent version of the TAP-Windows6 driver in a stand-alone package = there's no way to deinstall+reinstall the driver alone by hand anymore. I tried installing OpenVPN 2.6.4 (= one bugfix older) to see if that helps... no it doesn't.I tried to take a better look at what's going on. After some googling, I could come up with the following config options:
client config options added
verb 4
tap-sleep 5
route-delay 1 3
In the resulting client-side log, I can see (a snippet):
resulting log
2023-06-27 13:45:45 us=328000 PUSH: Received control message: 'PUSH_REPLY,[censored],topology net30,ifconfig 192.168.254.6 192.168.254.5,peer-id 0,cipher AES-256-GCM'
2023-06-27 13:45:45 us=328000 OPTIONS IMPORT: --ifconfig/up options modified
2023-06-27 13:45:45 us=328000 OPTIONS IMPORT: route options modified
2023-06-27 13:45:45 us=328000 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2023-06-27 13:45:45 us=328000 interactive service msg_channel=500
2023-06-27 13:45:45 us=359000 do_ifconfig, ipv4=1, ipv6=0
2023-06-27 13:45:45 us=359000 MANAGEMENT: >STATE:1687866345,ASSIGN_IP,,192.168.254.6,,,,
2023-06-27 13:45:45 us=359000 IPv4 MTU set to 1473 on interface 26 using service
2023-06-27 13:45:45 us=359000 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1473 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
2023-06-27 13:45:45 us=359000 Data Channel: cipher 'AES-256-GCM', peer-id: 0
2023-06-27 13:45:46 us=437000 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
2023-06-27 13:45:46 us=437000 Route: Waiting for TUN/TAP interface to come up...
2023-06-27 13:45:47 us=500000 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
2023-06-27 13:45:47 us=500000 Route: Waiting for TUN/TAP interface to come up...
2023-06-27 13:45:48 us=562000 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
2023-06-27 13:45:48 us=562000 Route: Waiting for TUN/TAP interface to come up...
2023-06-27 13:45:49 us=625000 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
2023-06-27 13:45:49 us=625000 MANAGEMENT: >STATE:1687866349,ADD_ROUTES,,,,,,
2023-06-27 13:45:49 us=625000 C:\Windows\system32\route.exe ADD 192.168.0.0 MASK 255.255.0.0 192.168.254.5 METRIC 200
2023-06-27 13:45:49 us=625000 Warning: route gateway is not reachable on any active network adapters: 192.168.254.5
2023-06-27 13:45:49 us=625000 C:\Windows\system32\route.exe ADD 192.168.2.0 MASK 255.255.254.0 192.168.254.5 METRIC 200
2023-06-27 13:45:49 us=625000 Warning: route gateway is not reachable on any active network adapters: 192.168.254.5
2023-06-27 13:45:49 us=625000 C:\Windows\system32\route.exe ADD 192.168.253.0 MASK 255.255.255.0 192.168.254.5 METRIC 200
2023-06-27 13:45:49 us=625000 Warning: route gateway is not reachable on any active network adapters: 192.168.254.5
2023-06-27 13:45:49 us=625000 C:\Windows\system32\route.exe ADD 192.168.254.1 MASK 255.255.255.255 192.168.254.5 METRIC 200
2023-06-27 13:45:49 us=625000 Warning: route gateway is not reachable on any active network adapters: 192.168.254.5
The "route-method" option is unspecified in my client config = default = probably "adaptive". But, I don't really think the "route method" is the culprit here, if the TAP interface remains down and without an address.
Apparently, although this is barely visible from the log, the TAP-Windows6 "virtual network adaptor" never reaches "connected" status, as reported by the various Windows GUI widgets - even while the OpenVPN gui reports, that the SSL-encrypted OpenVPN session has in fact been negotiated successfully.
If I try "ipconfig /all", I can see the TAP v9 port down = no link and no IP address obtained. No "directly connected" entry in the routing table, either.
In that case, it makes sense that the subsequent "route add" events fail.
I'm wondering why the "link up" is never achieved.
I'm wondering if the old "topology net30" might be to blame... perhaps Windows have added another check on the subnet parameters? Does the client side even get to know, that on the host side, this looks like a /24 subnet with a .1 as the interface address on he OpenVPN server machine?
I've noticed some OpenVPN support thread about this, for the commercial version 3.x.
This is something I can test, possibly later today (or early tomorrow) - I mean: "topology subnet". I don't quite believe that this could help, but it's not much work and therefore worth a try.
BTW, in the list of network adapters, I've found two more virtual "NIC's" related to OpenVPN:
"OpenVPN WinTun" and the "OpenVPN Data Channel Offload". Makes me wonder if these have anything to do with my "silent ifconfig failures".
Thanks in advance for any comments...