Page MenuHomeVyOS Platform

OpenVPN: IPv4 not working in client mode
Closed, ResolvedPublic

Description

After adding IPv6 support here: https://github.com/vyos/vyos-1x/commit/bb9f99853c723c5100c3fffbc592ba79f3abebfe#diff-b706c6ec71f1314215d25bf1fcec7c08R21
IPv4 only environments stopped working.

Some of the configurations has been fixed in T2339.
But the fix is based on the check of the local-host option only and does not address the client mode (local-host cannot be used in the client mode, must have remote-host configured instead).

Diagnostics is the same as in T2339:

Jun 03 19:13:39 vyos openvpn-vtun0[5441]: RESOLVE: Cannot resolve host address: x.x.x.x:1195 (Address family for hostname not supported)

Setting openvpn['protocol_real'] to 'udp' would apparently fix the issue.

If IPv6 protocols need to be set by default, remote-host could be also checked when in client mode to configure IPv4 protocols.

Details

Difficulty level
Unknown (require assessment)
Version
1.3-rolling-202006041824
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Event Timeline

mrozentsvayg created this task.
mrozentsvayg created this object in space S1 VyOS Public.

What happens when one remote-host is IPv4 and one is IPv6? The proposed fix would leave the protocol as udp6 in that case and the error would still be there.

I think we need to use connection profiles (openvpn man page: <connection>). I've thought that it would be good to add them when adding IPv6, but now it seems it's necessary to support different address families for remote addresses. Adding them would allow us to add even more features as each remote could have its own protocol, port, proxy, etc. (everything supported by the <connection> block). Ideally the config syntax would be extended to add all these and a migrator script to migrate the old remote-host to connection profiles.

In T2550#66208, @jjakob wrote:

What happens when one remote-host is IPv4 and one is IPv6? The proposed fix would leave the protocol as udp6 in that case and the error would still be there.

Yeah, this is intentional. I just followed an existing logic that forces IPv6 protocols by default here, and used v4 only in case when IPv6 is certainly not required.
However, i'm not sure why auto-sense was needed there in the first place, and instead would just make available the standard OpenVPN configuration approach:

proto indicates the protocol to use when connecting with the remote, and may be “tcp” or “udp”.
For forcing IPv4 or IPv6 connection suffix tcp or udp with 4/6 like udp4/udp6/tcp4/tcp6.

But may be there's some related background in vyos which i'm not aware of.

I think we need to use connection profiles (openvpn man page: <connection>). I've thought that it would be good to add them when adding IPv6, but now it seems it's necessary to support different address families for remote addresses. Adding them would allow us to add even more features as each remote could have its own protocol, port, proxy, etc. (everything supported by the <connection> block). Ideally the config syntax would be extended to add all these and a migrator script to migrate the old remote-host to connection profiles.

@mrozentsvayg look at https://community.openvpn.net/openvpn/ticket/360 (this is documented in the code comment right above your change as well). OpenVPN on Linux in server mode with standard protocols doesn't listen on IPv6, just IPv4. We need to force it to bind to a IPv6 socket using these undocumented *6 protocols, then it'll listen on both IPv4 and IPv6. This wouldn't be necessary if OpenVPN listened on IPv6 with the default protocols or autodetected whether the local or remote IPs are v4 or v6 and chose the correct socket type, but it doesn't. Complain to the above ticket 360. We're just working within the limitations imposed by OpenVPN.

The same issue is present in site-to-site mode. local-host can be set there, but should not be required as the WAN ip might be dynamic

c-po reopened this task as Needs testing.
c-po claimed this task.
erkin set Issue type to Bug (incorrect behavior).Aug 30 2021, 5:46 AM
erkin removed a subscriber: Active contributors.