A VPN requires a client and server. The “client” is the remote device (BATM, computer, or cell phone) that connects to the “server”. The OpenVPN server runs on the same server as your CAS installation.
This configuration is divided into 2 two parts: 1) the server configuration and 2) the client configuration. The server-side is done completed first, and the resulting OVPN files (from the server setup) are then sent to your “clients”: the users that will want to connect to the CAS GUI/server/front end.
Quick jump:
| Table of Contents | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
OpenVPN Server
Your CAS host runs an OpenVPN server. Other devices (clients) may then connect to your server to enjoy secure, protected access to CAS. This section described the first step: installing and configuring the server.
Install the required software.
...
Your CAS host runs an OpenVPN server. You connect to that server from a client. Every major OS (Windows, Linux, Mac, Android) supports a native OpenVPN client. This section described the second phase of OpenVPN setup: installing and configuring the client.
The OpenVPN settings required to connect to the server are contained in an OVPN file. That file is manually sent to each user, as explained above: Generate a OVPN file for CAS users
...
Only one client/OVPN file may be created for each CAS user.
You may use the same OVPN file on multiple devices,
as long as there is only one active connection per , only one device connected.
e.g you may use the same OVPN on your phone and laptop, but
you cannot use connect your phone and laptop at the same time.
...
the source is:
root@10.11.12.13/batm/vpngen/cli-adminusers/vpnUjdoe.ovpnthe target is:
.(a period represents “here”: the current directory).
Finally, using the above examples, this command would copy the OVPN source file to the current directory:
| Code Block |
|---|
scp root@10.11.12.13:/batm/vpngen/cli-adminusers/vpnUjdoe.ovpn ./ |
this example assumed assumes password authentication is currently enabled (default configuration).
WE URGE YOU TO Afterwards: AVOID USING PASSWORDS FOR SSH.
Implementing public keys are recommendedConvert to Public Key Authentication as soon as practical, and disable password-based SSH logins from that point forward.
Password-based logins can be very insecure.
Public Key Authentication is secure and well-documented on the Internet:
You may be asked to confirm the “authenticity of host”. If this is the first time you’ve connected to that server, then do soconfirm it. You should not encounter that obstacle again for that server (unless the server has been rebuilt or compromised). It is a security checkpoint.
Modified (if you have heeded our warnings and implemented public key SSH access):
...