OpenVPN is open source software that allows you to create encrypted VPN tunnels between devices, providing a secure way to communicate and access network resources.
In this post, we will show you how to create a safe tunnel to connect to an Asterisk. We will install a VPN server, certification authority and generate the necessary keys. Then we will configure the tool and make a test connection. Then we will use the tunnel to work with Asterisk, for example by logging in the phone.
Table of Contents
1) OpenVPN server installation
First, we will install the OpenVPN server itself and a set of tools for managing and creating an infrastructure of keys and certificates. We will need two packages
openvpn and easy-rsa
yum -y install openvpn easy-rsa
After successful installation, we will copy the OpenVPN server configuration file server.conf to another location where, for security reasons, we will set permissions for a user other than root. The Asterisk in the file name allows us to be independent of the version of the latest package.
cp /usr/share/doc/openvpn-*/sample/sample-config-files/server.conf /etc/openvpn/
2) Key generation
Now we will generate the necessary keys. Before we start this part of the configuration, we will delete all temporary files and any configuration files related to the current key and certificate infrastructure that may have been created in the past using the EasyRSA tool
cd /usr/share/easy-rsa/3.0.8/
./easyrsa clean-all
The next command will generate a new root certificate (CA – Certificate Authority) without having to enter a password.
./easyrsa build-ca nopass
The
nopass option indicates that you do not want to use a passphrase for the master key. In normal cases, when creating a private key or certificate, you are usually asked to enter a password to secure the private key. Using nopass means that the private key will be saved without a password, which may be convenient, but may also be less secure because the private key is then less secure. In our example, we will forgo this additional security everywhere. This will later make it easier for us to automate the entire process in subsequent installations and automatic communication with our environment. Storing private keys without a password may be less secure because the private key is less secure. Therefore, it is important to take appropriate precautions, especially when dealing with private keys used to secure communications in production environments.
The next command will generate a full set of server certificates without having to enter a password. This set typically includes the server certificate, the server’s private key, and the root certificate (CA) that signs the server certificate.
./easyrsa build-server-full server nopass
The “
server” argument, which indicates the server name or identifier that will be used to name the generated certificates.
“nopass“: This option means that the private key that will be generated for the server will not be password protected. This may be convenient, but it may also involve some security risks, as we wrote about above.
Now we will generate the Diffie-Hellman parameters (da). This command may take some time to complete, so please be patient.
./easyrsa gen-dh
Diffie-Hellman parameters include a large prime number and its corresponding generator that are used in the Diffie-Hellman key exchange process. This process is essential in establishing secure communications, especially in protocols such as TLS/SSL, where Diffie-Hellman parameters are used to negotiate a shared secret between the client and the server.
Diffie-Hellman (DH) is a cryptographic algorithm used to establish a shared secret between two parties in an unsecured communication channel. This shared secret can then be used for secure communication or to generate encryption keys.
Finally, we will generate a client certificate.
./easyrsa build-client-full client01 nopass
This EasyRSA command will create a full set of certificates and keys for the client called
client01. This command will generate a client certificate and the public and private keys associated with that certificate. The “nopass” option, of course, indicates that the private key will not be password protected and will not require a password when in use.
All generated keys landed automatically in the pki subdirectory. We can take a look at them
ls -lR pki/
For security purposes, we will move the server keys to a new subdirectory in the place where we already copied the OpenVPN server configuration file
mkdir /etc/openvpn/keys
cp pki/ca.crt /etc/openvpn/keys/
cp pki/dh.pem /etc/openvpn/keys/
cp pki/private/server.key /etc/openvpn/keys/
cp pki/issued/server.crt /etc/openvpn/keys/
We will need the client certificate and key later to connect to our machine
3) OpenVPN server configuration
Now that we have the sample
server.conf file copied from the installation directory, we will change the parameters pointing to the keys.
sed -i 's|^ca ca.crt$|ca /etc/openvpn/keys/ca.crt|' /etc/openvpn/server.conf
sed -i 's|^cert server.crt$|cert /etc/openvpn/keys/server.crt|' /etc/openvpn/server.conf
sed -i 's|^key server.key.*$|key /etc/openvpn/keys/server.key|' /etc/openvpn/server.conf
sed -i 's|^dh dh2048.pem$|dh /etc/openvpn/keys/dh.pem|' /etc/openvpn/server.conf
We will waive additional authentication for the Transport Layer Security (TLS) level security layer. It goes beyond the standard SSL/TLS level of security
sed -i 's|^tls-auth ta.key.*$|; &|' /etc/openvpn/server.conf
We will also set the
nobody user and group for the OpenVPN runtime. This means that OpenVPN will be run with nobody user and group permissions, which is good security practice to mitigate potential risks from access to administrative privileges if OpenVPN were to be run as a user with high privileges. To do this, we will uncomment existing proposals for such action in the configuration file.
sed -i 's|^;user nobody$|user nobody|' /etc/openvpn/server.conf
sed -i 's|^;group nobody$|group nobody|' /etc/openvpn/server.conf
4) Launching and testing OpenVPN
First, we will add OpenVPN to startup
systemctl enable openvpn@server.service
We will then start the service and check its status
systemctl start openvpn@server.service
systemctl status openvpn@server.service
We will get a screen similar to the one below.
5) Connecting to the server using OpenVPN
With the generated keys, we will create an OpenVPN client configuration file used to connect to our VPN environment. In notebook, we create a file with the
ovpn extension with the following structure
client
dev tun
remote N.N.N.N 1194 udp
cipher AES-256-CBC
data-ciphers AES-256-CBC
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256
auth SHA1
nobind
resolv-retry infinite
persist-key
persist-tun
verb 0
auth-nocache
<ca>
-----BEGIN CERTIFICATE-----
//Here we paste the certificate from the file ca.crt //
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
//Here we paste the certificate from the file client01.crt //
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
//Here we paste the certificate from the file client01.key //
-----END PRIVATE KEY-----
</key>
If we have OpenVPN software installed in a Windows environment (e.g. OpenVPN), we can double-click on such a file to import it and then select the connect option. We should be able to connect and get an IP address
From now on, we can use a secure VPN connection
5) Using an OpenVPN connection to work with the Asterisk system
Once we have a secure connection to our server where we have the Asterisk system installed, we can now connect to its services using a VPN tunnel. Thanks to this, we don’t have to worry about unblocking sensitive ports on our firewall and exposing them to the world. From now on, our clients will connect to the Asterisk system using internal addresses. Let’s look at the current network configuration.
ip a
In position no. 3, described as tun0: we have the address of our switchboard, which we can use for a secure connection. It’s 10.8.0.1. If we now run the command showing the status of our tunnel, we will see this address and our connection.
systemctl status openvpn@server.service -l
Our Windows client: client-01 received the address 10.8.0.6 and connected to the server at the address 10.8.0.1. Now we can use this connection to securely log our phone into the Asterisk PBX using a private IP address. In the softphone configuration, we enter a private address instead of a public one.
After logging in the phone to the PBX, we see it from the CLI console as accessible through the private IP address that we received after connecting via the 10.8.0.6 tunnel
asterisk -rx "sip show peers"
Additionally, in the Asterisk logs we can see the activity that has just been performed.
tail -f /var/log/asterisk/messages
We can use the tunnel created in this way to connect to the Manager of our Asterisk PBX (AMI) or, for example, to a website installed on our server (e.g. in FreePBX or Elastix). We then do not have to reduce the security of our system by exposing sensitive ports to the world.
Do you know what is really happening on your PBX? Try our proprietary software VOIPERO.
Installation and configuration takes a few minutes and the system is currently available totally free
Find out what the VOIPERO system has to offer when it comes to reporting and live monitoring of VoIP systems based on Asterisk.
