RMS Users VPN configuration file

When using an RMS Users VPN configuration file “.ovpn” to connect to a RUT140 VPN, the OpenVPN connection is established successfully, but no password is requested. Could this pose a security risk? I feel it would be more secure to require a username and password to secure the VPN. Is this possible?

Thanks

Answer at this link.

Hello @Marcelo.Barros ,

Indeed, this video explains how to create the VPN, but it does not explain how to secure the OpenVPN configuration file with a password.

Thanks for this URL.

Greetings,

Thank you for reaching out and apologies for the late response.

Your OpenVPN connection generated via RMS is already secure as configured, even without requiring a username and password. RMS VPN utilizes TLS certificate-based authentication rather than traditional login credentials. The generated .ovpn configuration file contains an embedded client certificate and a unique private key, ensuring all data passing through the tunnel to your RUT140 is encrypted.

In this setup, the .ovpn file itself acts as your digital access key. As long as the file remains safely stored on your authorized device and is not shared, your network connection remains protected.

For more technical details on how RMS VPN operates, you can refer to our documentation here: RMS VPN Hubs - Teltonika Networks Wiki

If you have any further questions, please don’t hesitate to reach out!

Best regards,
Martyna

Hello Martyna,

Thank you for your reply and for the clarification on how RMS VPN operates.

I fully understand that authentication relies on TLS certificates rather than a username/password pair, and that the tunnel itself is properly encrypted. However, that is not the point behind my request.

The issue is not the security of the tunnel, but the protection of the .ovpn file itself. In the current configuration, the embedded private key is not encrypted (no “ENCRYPTED PRIVATE KEY” block). This means that anyone who obtains this file — through theft of a device, a USB drive, an improperly secured backup, or even an accidental copy — can immediately establish a VPN connection to the equipment, with no additional secret required. The file acts as both the identifier and the access key, with no second factor.

Your own documentation confirms this concern: it states that “the .ovpn file itself acts as your digital access key.” That is precisely the issue — a single file, with no additional protection, grants full access.

The request is therefore straightforward: that the private key generated in the .ovpn file be password-protected (“ENCRYPTED PRIVATE KEY” format, standard OpenSSL/OpenVPN). This is a standard practice recommended by OpenVPN itself for sensitive deployments, and it has no impact on the TLS certificate mechanism you described — it simply adds a layer of protection at rest.

There is also a regulatory dimension to this request. The new EU Machinery Regulation (EU) 2023/1230 becomes mandatory on 20 January 2027, and it introduces explicit cybersecurity requirements for machinery with connected or networked safety-related control systems. An unencrypted private key embedded in a VPN configuration file could reasonably be flagged during a CE conformity assessment as an inadequate safeguard against unauthorized remote access, and could become a ground for refusing certification. We need to be able to demonstrate that remote access credentials are protected at rest, not only in transit.

Could you confirm whether RMS offers an option to generate .ovpn files with a password-protected private key, or, failing that, whether this feature is on your roadmap?

I remain available to discuss this further if needed.

Best regards,
Florent