Network routing and addressing options for Conferencing Nodes

This section describes Pexip Infinity's network routing and addressing configuration options that are often required when deploying Conferencing Nodes in a public DMZ, or when routing to a dedicated video zone. It covers the following scenarios:

Note that in all Pexip Infinity deployment scenarios:

  • The Management Node must be able to reach all Conferencing Nodes (Proxying Edge Nodes and Transcoding Conferencing Nodes) and vice versa.
  • Each Conferencing Node must be able to reach every other Conferencing Node (Proxying Edge Nodes and Transcoding Conferencing Nodes), except:
    • When a location contains Proxying Edge Nodes, those nodes only require IPsec connectivity with:

      • any other proxying nodes in that location
      • all nodes in the transcoding location, and the primary and secondary overflow locations that are associated with that location
      • the Management Node.

      This means that the proxying nodes in one location do not need to have a direct network connection to other proxying nodes in other locations.

  • Any internal firewalls must be configured to allow UDP port 500 and traffic using IP protocol 50 (ESP) in both directions between all Pexip nodes.
  • There cannot be a NAT between any Pexip nodes.

In addition, you must ensure that all appropriate firewall ports have been opened as described in Pexip Infinity port usage and firewall guidance.

Further information is available in Network deployment options, Firewall/NAT routing and addressing examples and Deployment guidelines for Proxying Edge Nodes.

Configuring Pexip Infinity nodes to work behind a static NAT device

To configure your Pexip Infinity deployment to work behind a static NAT device (from the perspective of clients located on the Internet or in a dedicated video zone) you must:

  1. Configure the NAT device / firewall with the static, publicly-reachable IP address of each Conferencing Node that you want to be accessible from devices in the internet / video zone, and then map the public address to the node's corresponding internal IP address. Note that it must be a 1:1 NAT.
  2. Configure each publicly-reachable Conferencing Node with its IPv4 static NAT address (Platform > Conferencing Nodes) i.e. the public address of the node that you have configured on the NAT device.

Note that:

  • Any Conferencing Nodes that are configured with a static NAT address must not be configured with the same System location as nodes that do not have static NAT enabled. This is to ensure that load balancing is not performed across nodes servicing external clients and nodes that can only service private IP addresses.
  • Static NAT must be on the secondary interface if the Conferencing Node has dual network interfaces.
  • Any internal systems such as Cisco VCSs or endpoints that will send signaling and media traffic to Pexip Infinity nodes that are enabled for static NAT should send that traffic to the public address of those nodes. You must ensure that your local network allows this.
  • We do not recommend that you allow the Management Node to be accessible from devices in the public internet. However, if you want to do this, you must assign and configure the Management Node with its static NAT address. You should also configure your firewall to only allow access to the Management Node from the specific IP addresses from where you want to allow management tasks to be performed.
  • There cannot be a NAT device between any Pexip Infinity nodes.

Deploying Conferencing Nodes with dual network interfaces (NICs)

For additional deployment flexibility, you can configure a secondary network address on a Conferencing Node.

You would typically deploy a Conferencing Node with dual network interfaces when it is connected to a dedicated video zone or it is being deployed in a public DMZ where the primary interface would be to an internal, private network segment within the enterprise (where it can connect to the Management Node and other Conferencing Nodes) and the secondary interface would be towards the video zone or on the publicly-addressable side of the DMZ perimeter network and used for connecting to external endpoints and devices.

As with specifying the IP address of a Conferencing Node with a single interface, the IP address and network mask of the secondary interface must be specified when the Conferencing Node is initially deployed and cannot be subsequently modified.

When a secondary network address is configured:

  • The primary address is always used for inter-node communication to the Management Node and to other Conferencing Nodes.
  • SSH connections can be made only to the primary interface.
  • The secondary address is always used for signaling and media (to endpoints and other video devices).
  • Connections to DNS, SNMP, NTP, syslog and so on, go out from whichever interface is appropriate, based on routing.
  • You can have a mixture of any number of single-interfaced and dual-interfaced Conferencing Nodes, providing all nodes can communicate with each other via their primary interfaces.
  • Each interface must be in a different subnet.
  • The Conferencing Node's default gateway can be in either subnet and is automatically associated with the correct interface. For the typical DMZ deployment scenario where the secondary NIC is the public NIC, the default gateway sits on the secondary NIC.
  • Static routes can be in either subnet and are automatically associated with the correct interface.
  • Static NAT, if configured, must be on the secondary interface.

Applying static routes to enable routing between externally-facing nodes and local network nodes

In some deployment scenarios you may have the Management Node and some Conferencing Nodes deployed in the local enterprise network, and some Conferencing Nodes deployed in a public DMZ or connected to a dedicated video zone.

If the default gateway on those non-local nodes is configured to route traffic out to the internet / video zone, you will need to configure static routes on those Conferencing Nodes to allow them to communicate with Pexip Infinity nodes or other systems in the local, internal network. See Managing static routes for information about to how to configure and assign static routes to Pexip Infinity nodes.

In situations where the Conferencing Node's default gateway is not towards the Management Node, the static route back to the Pexip Infinity platform must be applied to the Conferencing Node during its initial deployment phase (otherwise it will not be able to communicate with the Management Node and pick up its configuration).

Note that:

  • Conferencing Nodes in a DMZ must not be configured with the same System location as nodes in a local network. This is to ensure that load balancing is not performed across nodes in the DMZ and nodes in the local network.
  • You must configure any internal firewall to allow UDP port 500 and traffic using IP protocol 50 (ESP) in both directions between the Pexip Infinity nodes in the DMZ and the nodes in the local network.
  • The firewall between the Pexip Infinity nodes in the DMZ and the nodes in the local network cannot be a NAT device.
  • The external firewall between Conferencing Nodes in the DMZ and the internet can be configured with static NAT. In this case you would also need to configure each Conferencing Node in the DMZ with its relevant static NAT address.
  • If you deploy the Management Node in the DMZ (although we do not recommend this for security reasons), it must also be assigned with the relevant static route (Platform > Management Node).

Example

For example, consider a Pexip Infinity system which is deployed as shown below:

Example network with Pexip Infinity nodes in LAN and DMZ

This deployment has:

  • Pexip Infinity nodes on the enterprise LAN with addresses in the 10.40.0.0/24 subnet
  • an internal firewall (without NAT) with LAN address 10.40.0.1 and DMZ address 172.16.0.10
  • an external firewall with DMZ address 172.16.0.30 and public address 198.51.99.200
  • a Conferencing Node in the DMZ with a single network interface with address 172.16.0.40 and which is configured with a default gateway address of 172.16.0.30 (the external firewall).

In this situation the Conferencing Node in the DMZ will, by default, send all of its traffic out through its default gateway — the external firewall at 172.16.0.30. To ensure that traffic from the Conferencing Node in the DMZ that is destined for Pexip Infinity nodes on the enterprise LAN can be routed to those nodes, you must deploy the Conferencing Node with a suitable static route applied to it. In this example the Destination network address of the static route would be 10.40.0.0 with a Network prefix of 24 (to route addresses in the range 10.40.0.0 to 10.40.0.255) and the Gateway IP address would be 172.16.0.10 (the DMZ address of the internal firewall).

Remote SIP endpoints behind a remote firewall/NAT

Remote SIP endpoints that are behind remote firewalls/NATs can join Pexip Infinity conferences.

Media latching with remote endpoints behind a remote firewall/NAT

You do not have to apply any explicit configuration to Conferencing Nodes in order to allow remote SIP endpoints behind remote firewalls/NATs to join a conference. Pexip Infinity automatically uses signaling and media port latching to establish routable paths.

(Port latching involves Pexip Infinity waiting until it receives signaling and media traffic from the remote endpoint, and then it uses — or "latches" on to — the source address and port of that traffic as a destination for all traffic bound in the opposite direction. Typically these source addresses/ports will belong to the public interface of the NAT in front of the remote endpoint, and thus anything sent by Pexip Infinity to that address/port should ultimately reach the endpoint.)