Extra configuration and maintenance tasks for the Reverse Proxy and TURN Server

This section describes some additional configuration scenarios and maintenance tasks for the reverse proxy and TURN server:

If you are using v5 (or earlier) of the OVA template, refer to the previous documentation for the appropriate instructions.

Patching the operating system for the latest security bugs

Note that version 6.x and earlier deployments no longer receive OS security fixes from Canonical. We strongly recommend that all customers should upgrade to version 7.x.

We recommend that you keep the appliance's Operating System patched against the latest security bugs. The frequency with which you check for patches depends upon your local security policies but we recommend at least once per month, or whenever an important or critical CVE (Common Vulnerabilities and Exposures) has been resolved in Ubuntu.

Note that some updates may need some of the system services to be restarted or require a reboot of the VM, so we recommend performing these updates when a potential temporary loss of service is acceptable.

To install the latest security patches:

  1. Take a VM snapshot of the appliance.
  2. Log in to the server through SSH or VMware console as user 'pexip'.
  3. Run the following command:

    sudo apt-get update && sudo apt-get dist-upgrade

  4. Delete the snapshot after 1-2 days, when it has been confirmed that the patches have not had any detrimental effect.

Configuring the operating system to use a proxy for software upgrades

To configure the appliance's operating system to use a proxy for software upgrades:

  1. Connect over SSH to the reverse proxy.
  2. Create a proxy configuration file on the appliance with the following command:

    sudo nano /etc/apt/apt.conf.d/proxy.conf

  3. Add the following contents via the text editor:

    Acquire {
      HTTP::proxy "http://user:password@proxy.server:port/";
      HTTPS::proxy "http://user:password@proxy.server:port/";
    }

    where the user and password credentials and the proxy's hostname/port are configured as appropriate, for example:

    Acquire {
      HTTP::proxy "http://proxyuser:Abcd$1234@proxy.example.com:8181/";
      HTTPS::proxy "http://proxyuser:Abcd$1234@proxy.example.com:8182/";
    }
  4. Press Ctrl + O to save your changes.
  5. Press Ctrl + X to exit nano.
  6. To verify that your configuration file and proxy are working correctly, you can run the following command and check that no errors are reported:

    sudo apt-get update

Rerunning the install wizard

Many of the maintenance tasks to change the configuration of the Reverse Proxy and TURN Server involve rerunning the installation wizard.

To rerun the installation wizard:

  1. Log in to the Reverse Proxy and TURN Server through SSH or VMware console as user 'pexip'.
  2. At the command prompt, run the installwizard command.
  3. At each step the default values use the answers from the previous run (if they are still valid).

    Press ENTER to accept the default value, or enter the value you want to use instead.

  4. When all of the installation wizard steps have been completed, the appliance automatically reboots.

Adding or removing Conferencing Nodes from an existing reverse proxy or TURN server configuration

To add an additional Conferencing Node, or to remove a Conferencing Node from an existing reverse proxy or TURN server configuration:

  1. Log in to the reverse proxy/TURN server through SSH or VMware console as user 'pexip'.
  2. At the command prompt, run the installwizard command.
  3. Go through the installation steps accepting the default answers (to preserve the previous settings) until you get to step 5 Web reverse proxy (step 7 if you have dual NICs).
  4. If you are using the reverse proxy functionality, answer "yes" when asked "Enable web reverse proxy?", and then:

    1. The existing signaling Conferencing Node addresses are listed and you are asked "Use these default values?".

      Reply "no".

    2. You are asked "IP Address of signaling Conferencing Node 1?"

      Re-enter all of the addresses of your new set of Conferencing Nodes i.e. from the existing list re-enter the addresses of the nodes you want to keep, add the addresses of any additional nodes, and do not re-enter the addresses of any nodes you want to remove from the list.

      Enter each address one at a time, pressing ENTER after each address, and then add an empty line when finished.

  5. At step 6 TURN server (step 8 if you have dual NICs), if you are using the TURN server functionality answer "yes" when asked "Enable TURN server?", and then:

    1. The existing media Conferencing Node addresses are listed and you are asked "Use these default values?".

      Reply "no".

    2. You are asked "IP Address of media Conferencing Node 1?"

      Re-enter all of the IP addresses of your new set of Conferencing Nodes i.e. from the existing list re-enter the addresses of the nodes you want to keep, add the addresses of any additional nodes, and do not re-enter the addresses of any nodes you want to remove from the list.

      Enter each address one at a time, pressing ENTER after each address, and then add an empty line when finished.

  6. Complete the remaining steps in the install wizard accepting the default answers (to preserve the previous settings).
  7. When all of the installation wizard steps have been completed, the appliance automatically reboots.

Configuring the TURN server for TCP TURN relay

In normal circumstances, WebRTC clients connecting to a Pexip environment use HTTPS (TCP port 443) for call signaling, while sending RTP media (audio+video+presentation) via UDP (Chrome and Firefox also supports TCP media as a fallback). RTP media generally uses ephemeral highports — Conferencing Nodes use ports 40000-49999 by default and Pexip-provided TURN server uses UDP 49152-65535 for media.

These ephemeral highport ranges can cause a problem if the WebRTC client is behind a strict firewall setup. Strict firewalls tend to limit the outbound connections allowed from a client PC to well-known ports and/or protocols, for instance only allowing TCP/80 (HTTP), TCP/443 (HTTPS) and UDP/53 (DNS). In this case, for example, when the client attempts to send RTP media to a Pexip node on port 40120, these RTP packets will be blocked by the firewall, and thus the client cannot receive or send any media.

A workaround for this type of issue is to set up a TURN server specifically for such clients, where this TURN server listens for incoming TURN traffic on a well-known port (where this well-known port is likely to be allowed on the strict firewall). TCP port 443 is an example of such a well-known port, where it is likely, but not guaranteed, that the WebRTC client will be able to communicate with an arbitrary host located on the Internet over this port.

Note that sending TURN media over TCP 443 is not the same as encapsulating RTP inside of HTTP(S). In this case, we are simply using a well-known port (TCP 443) to send RTP media, where this well-known port in normal circumstances is used to send HTTPS traffic. This means that if the WebRTC client is located behind a web proxy (where all traffic between the client and the Internet is funneled via this web proxy), this approach is not likely to work since the web proxy will recognize that this RTP media is not actual HTTPS traffic and therefore drop the packets. This approach will therefore only work with "dumb" firewalls which only evaluate the port and network protocol for the traffic in question, and where the firewall disregards the application protocol that is being used across this network connection.

The following diagram shows a WebRTC client (running Chrome or Firefox), located behind a strict firewall, as well as a TURN server and Pexip Conferencing Nodes which are located on a public network. This strict firewall only allows a certain set of ports for outbound communication from Chrome client, and in this example, TCP/443 is one of the outbound destination ports that are allowed. When configured correctly, the client will first establish WebRTC signaling to the Conferencing Nodes (signaling is not shown in this diagram), and then receive TURN server provisioning information from the Conferencing Node which instructs the client to use STUN/TURN with this TURN server.

After the WebRTC client has established a relationship with the TURN server, the client can send RTP media to the TURN server over a single TCP port, and the TURN server will forward (relay) these RTP packets to the appropriate Conferencing Node over UDP as normal. Similarly, the Conferencing Node can send RTP media back to the WebRTC client via the same connection.

Note that:

  • When using TCP/443 as the single TURN port, the client TURN server cannot coexist with a reverse proxy application as the reverse proxy also uses TCP/443. Therefore you should set up a dedicated VM instance for the client TURN role. The installation wizard does not allow you to enable both the reverse proxy and TURN over TCP/443 on the same appliance.
  • In versions prior to 6.1.0 of the TURN server, clients may still use UDP media relays, if those media paths can be established (via ICE negotiation). As of version 6.1.0, clients are unable to use media relays over UDP/3478 as their addresses will not be in the safelist of allowed IP addresses for UDP media relay that is configured via the installation wizard.
  • As of version 6.1.0 of the TURN server, clients can relay media only to the safelist of allowed IP addresses for UDP media relay (as communication between the TURN server and Conferencing Nodes always uses UDP/3478).
  • As general good practice, we always recommend deploying the TURN server in a suitably secured network segment, such as a DMZ.

  • In some deployments, the Conferencing Nodes are themselves behind dynamic NAT, which means that these Conferencing Nodes also require a TURN server to exchange RTP with external hosts. In this case we recommend that you deploy a separate TURN server (where TURN over TCP/443 is not enabled) for use by these Conferencing Nodes.

To deploy TCP TURN relay:

  1. Deploy a TURN server for TURN over TCP/443:

    1. Start deploying the Pexip RP/TURN OVA template as usual.
    2. Follow the installation wizard and ensure that you make the following responses when asked:

      Prompt Response
      Enable web reverse proxy? no
      Enable TURN server? yes
      Do you want the TURN server to listen on port 443 instead of 3478? yes
  2. Configure Pexip Infinity to provision Connect web apps with instructions to use this TURN server:

    1. Go to Call control > TURN servers and add the details of the TURN server you have just deployed.

      Ensure that you specify port 443 and TCP transport.

    2. Go to Platform > Locations and, for each appropriate location containing Conferencing Nodes that the WebRTC clients will connect to, add the TURN server to the set of Client TURN servers.

Now, when a Connect web app connects to a Conferencing Node, it will be provisioned with the address of the client TURN server to use for its media routing.

Configuring NAT for the TURN server

To configure NAT for the TURN server, run the following command to edit the TURN server configuration:

sudo nano /etc/turnserver.conf

Anywhere in the config file, add the parameter external-ip=1.2.3.4, where 1.2.3.4 is the public NAT address of the TURN server.

After editing the file, run the following command to make the configuration change take effect:

sudo systemctl restart coturn

Note that this will interrupt any existing TURN sessions (e.g. any WebRTC or Skype for Business calls going via the TURN server), therefore these changes should be performed during a maintenance window that is outside of normal operating hours.

Changing between single NIC and dual NIC

To change the configuration of your appliance from single NIC to dual NIC (or vice versa) you should rerun the installation wizard:

  1. Log in to the reverse proxy/TURN server through SSH or VMware console as user 'pexip'.
  2. At the command prompt, run the installwizard command.
  3. At step 1 of the install wizard it will detect how many NICs are available and present the appropriate options as described in Running the installation wizard.

    Answer the network interfaces questions and include any custom network routes as appropriate.

  4. Complete the remaining steps in the install wizard accepting the default answers (to preserve the previous settings).
  5. When all of the installation wizard steps have been completed, the appliance automatically reboots.

Changing the TURN server's access credentials

To set new access credentials for the TURN server, rerun the installation wizard:

  1. Log in to the reverse proxy/TURN server through SSH or VMware console as user 'pexip'.
  2. At the command prompt, run the installwizard command.
  3. Go through the installation steps accepting the default answers (to preserve the previous settings) until you get to step 6 TURN server (step 8 if you have dual NICs).
  4. Keep your default answers for the "Enable TURN server?" and "Do you want the TURN server to listen on port 443 instead of 3478?" prompts.
  5. Specify your new TURN server credentials for the "Username?" and "Password?" prompts.
  6. Complete the remaining steps in the install wizard accepting the default answers (to preserve the previous settings).
  7. When all of the installation wizard steps have been completed, the appliance automatically reboots.

Note that the realm in use in your deployment is set to the value of Domain as specified in that installation wizard. You can also check this by looking at your TURN server configuration file (by running cat /etc/turnserver.conf) and checking the realm= line.

If you change the credentials, remember to update the TURN server configuration on Pexip Infinity (Call control > TURN servers).

Restoring the Reverse Proxy and TURN Server to its default state

To reset the appliance to its default state you must either redeploy the appliance VM from the original OVA file, or restore a snapshot taken after initially deploying the OVA template with its default values.