Configuring Pexip Infinity for public DMZ deployments

This section describes the configuration requirements for deploying Pexip Infinity Conferencing Nodes in a public DMZ (see Network deployment options for more information). It covers the following scenarios:

• Configuring Pexip Infinity to work when Conferencing Nodes are behind a static NAT device (from the perspective of clients located on the Internet)
• Enabling routing between nodes deployed in a local network and publicly-facing nodes deployed in a DMZ
• Communicating with remote SIP endpoints behind a remote firewall/NAT

Note that in all Pexip Infinity deployment scenarios:

• All Pexip nodes must be fully routable to each other (full mesh) in both directions. This means that the Management Node must be able to reach every Conferencing Node, and each Conferencing Node must be able to reach every other Conferencing Node.
• 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.

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) 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, 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 configuration > 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.
• 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.

Enabling routing between local network nodes and DMZ nodes

In public DMZ deployments you will typically have the Management Node and some Conferencing Nodes deployed in the local enterprise network, and some Conferencing Nodes deployed in the DMZ.

In this case, you will also need to configure static routes on any Conferencing Nodes that are deployed in the DMZ, if the default gateway on those nodes is configured to route traffic out to the internet. The static routes will allow those nodes 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.

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 configuration > Management Node).

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 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:

1. Configure a static route (System configuration > Static routes). In this example:
   • the Destination network address 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
   • the Gateway IP address would be 172.16.0.10 (the DMZ address of the internal firewall).

   

2. Assign that static route to the Conferencing Node that is located in the DMZ (Platform configuration > Conferencing Node).

Remote SIP endpoints behind a remote firewall/NAT

You do not have to apply any explicit configuration to the Pexip Infinity 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.)