Upgrade client v2 to v3

[dcendents]

Hi,

We have a OpenVPN AS server running and on the client side users will use openvpn v2 client from the Ubuntu apt repository.
One of them tried to use the V3 client and couldn't connect because it does not report the MAC address like V2 does, and the client_reason from the post_auth script is not displayed back to the user.

So I have 2 question regarding V3.

1. Is there any way we could send the MAC address to the server?

   • I don't want to "dumb" down the security for the IV_HWADDR value, but in our case we need the MAC address to query an external API to make sure our active security service is running and reposrting on the device trying to connect.
   • Can we add custom fields and client-side logic to send the MAC address?

2. How can we display the client_reason value to the user?

   • They are users, they are not interested in changing the log level and digging in log files. When the connection is refused, they want to know the reason and not a generic connection refused message.

For the first issue, I suppose we could build a database on our side to correlate the ID to the device to be able to do our extra security check before we allow the connection. But for the second, in term of user experience we will get a big push back if we cannot easily display a meaningful message back to them.

Thanks

[dsommers]

1. No, there is no support for sending MAC addresses in OpenVPN 3 Linux, and that is not being planned. The reason is simply that it is generally a very fragile identifier. On some setups, switching from a wired to a wireless interface can change this string. And there are discussions in the OpenVPN 2.x community as well, to move away from the "MAC address" value.
2. This is actually something we should look into implementing into the OpenVPN 3 Linux client. I agree that log itself are not suitable for end users figuring out this. And the front-ends the user uses should provide this information. I'll put that on the TODO list.

I would generally recommend you to start tracking the reported IV_HWADDR values and not expect it to be MAC addresses. Currently the IV_HWADDR is fixed per installation. It is a hashed value seeded with the value from /etc/machine-id or if the value is set via the systemd.machine_id=... kernel command line option. If neither of these are available, it will generate a seed and store that under /var/lib/openvpn3. The value being sent can be seen using this command openvpn3-admin variables --machine-id. That will also provide details how the information was retrieved (details here).

We are looking into "hardening" this value even further, for example by including the top-level domain the user connects to in the hashing, so that each site (VPN service) has a static unique IV_HWADDR. But we are still evaluating the best approach and various alternatives. But the overall idea is to have a fairly stable and unique identifier per connecting client hardware/OS, regardless where/how they connect from.

[dcendents]

Thanks for your answer.

We know the MAC address is fragile but we are not using it for security purpose in itself to allow or deny the connection using a list of allowed MAC addresses. If this was the case we could simply use the new ID which is in fact more secure and harder to spoof.

But currently the MAC address is an ID that we can use to query an external system to make sure the proper monitoring tool is still installed on the device. Since we can use any MAC address to find the device it was not a problem for us to get either the wired or wireless address.

We'll keep using the V2 client for now and will plan in the work to stop relying on the mac address being sent by the client in the future.

Thanks