Page MenuHomeVyOS Platform

openvpn: server default topology net30 is incompatible with static client IPs for Windows clients
Open, HighPublic

Description

If openvpn server topology is unset, openvpn >2.0 defaults to net30. Setting static IPs for clients with server client ip then generates ifconfig-push statements that aren't /30 subnets but are the subnet set for the server itself. Linux clients keep working but Windows clients fail with the error:

There is a problem in your selection of --ifconfig endpoints [local=192.0.2.12, remote=192.0.2.1]. The local and remote VPN endpoints must exist within the same 255.255.255.252 subnet. This is a limitation of --dev tun when used with the TAP-WIN32 driver. Try 'openvpn --show-valid-subnets' option for more info.

The config that produces the above error:

openvpn vtun0 {
    encryption {
        ncp-ciphers aes256gcm
    }
    hash sha512
    local-host x.x.x.x
    mode server
    persistent-tunnel
    server {
        client client1 {
            ip 192.0.2.10
        }
        client client2 {
            ip 192.0.2.12
        }
        subnet 192.0.2.0/24
    }
    tls {
        ca-cert-file /config/auth/ca.crt
        cert-file /config/auth/server.crt
        crypt-file /config/auth/tls.key
        dh-file /config/auth/dh.pem
        key-file /config/auth/server.key
    }
}

Example ccd from the above config:

### Autogenerated by interfaces-openvpn.py ###

ifconfig-push 192.0.2.20 255.255.255.0

The following is the output of openvpn.exe --show-valid-subnets on Windows:

openvpn.exe --show-valid-subnets
On Windows, point-to-point IP support (i.e. --dev tun)
is emulated by the TAP-Win32 driver. The major limitation
imposed by this approach is that the --ifconfig local and
remote endpoints must be part of the same 255.255.255.252
subnet. The following list shows examples of endpoint
pairs which satisfy this requirement. Only the final
component of the IP address pairs is at issue.

As an example, the following option would be correct:
--ifconfig 10.7.0.5 10.7.0.6 (on host A)
--ifconfig 10.7.0.6 10.7.0.5 (on host B)
because [5,6] is part of the below list.

[ 1, 2] [ 5, 6] [ 9, 10] [ 13, 14] [ 17, 18]
[ 21, 22] [ 25, 26] [ 29, 30] [ 33, 34] [ 37, 38]
[ 41, 42] [ 45, 46] [ 49, 50] [ 53, 54] [ 57, 58]
[ 61, 62] [ 65, 66] [ 69, 70] [ 73, 74] [ 77, 78]
[ 81, 82] [ 85, 86] [ 89, 90] [ 93, 94] [ 97, 98]
[101,102] [105,106] [109,110] [113,114] [117,118]
[121,122] [125,126] [129,130] [133,134] [137,138]
[141,142] [145,146] [149,150] [153,154] [157,158]
[161,162] [165,166] [169,170] [173,174] [177,178]
[181,182] [185,186] [189,190] [193,194] [197,198]
[201,202] [205,206] [209,210] [213,214] [217,218]
[221,222] [225,226] [229,230] [233,234] [237,238]
[241,242] [245,246] [249,250] [253,254]

A quick fix/workaround is setting topology subnet, which works with the same config for both Linux and Windows clients. Interestingly, net30 isn't even an option for subnet, while openvpn defaults to it if subnet is unset. net30 should probably be added as an option to topology.

I think the script should have this list of allowed IP pairs and only allow setting client IPs to a valid IP in a pair, with the completion and value help getting the list of allowed IPs from the script, only when net30 is selected (all free IPs in the server subnet are valid in subnet topology so this needs to be done conditionally). The ifconfig-push command is also different between net30 and subnet topologies

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Behavior change
Issue type
Bug (incorrect behavior)

Event Timeline

jjakob created this object in space S1 VyOS Public.
jjakob updated the task description. (Show Details)

The recent work on openvpn added net30 as an option for "server topology" and marked it as default in the shell value help so at least users should now know it's the default. Personally I'd like the default topology to be subnet but that would mean adding a migrator script for old users who use net30.
It also rewrote some parts of the ifconfig setting logic. This should be retested if it's still an issue.

erkin set Issue type to Bug (incorrect behavior).Aug 31 2021, 5:15 PM