Alternative dual NIC reverse proxy/TURN server deployment
This section shows an alternative dual NIC network configuration 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.
In this example, the environment is split into two parts: an internal, private network segment and a DMZ network. The private network has two Conferencing Nodes and the reverse proxy/TURN server internal interface, while the DMZ perimeter network contains the reverse proxy/TURN server external interface.
Note that all IP addresses in this guide are examples only — actual IP addressing is deployment specific.
The reverse proxy/TURN server in this case has two network interfaces:
- An internal facing interface (IP address 10.40.0.2) which is connected to the internal LAN network.
- An external facing interface (IP address 198.51.100.130) which is connected to the DMZ network.
The internal interface of the reverse proxy/TURN server is configured on the same subnet as the Conferencing Nodes, while the external interface of the reverse proxy/TURN server is configured on the DMZ subnet. The Conferencing Nodes use 10.40.0.1 as their default gateway. This is also the gateway to the 10.0.50.0/24 management network, from where SSH connections to the internal interface of the reverse proxy/TURN server will originate.
There is no NAT between the outside and the DMZ network segment. The reverse proxy/TURN server uses the DMZ firewall 198.51.100.129 as its default gateway, and is also configured with a static route to the 10.0.50.0/24 management network via the LAN gateway at 10.40.0.1 so that SSH management traffic from this management network can function.
To deploy the reverse proxy/TURN server in this configuration:
- Deploy the Reverse Proxy and TURN Server appliance OVA file and power on the VM instance.
Complete the installation wizard steps for NIC configuration:
Prompt Example input Comments <list of detected NICs>
Do you want to configure Dual NIC?
yes This option is only presented if multiple NICs are detected. Which is the internal-facing network interface? eth0 Enter the name of the NIC that will be the internal-facing interface. Which is the external-facing network interface? eth1 If there are just two NICs this is automatically filled with the name of the other interface. IP Address for internal interface? 10.40.0.2 The IP address of the internal interface of the appliance. Subnet mask for internal interface? 255.255.255.0 The network mask for the internal interface. Add a custom network route for <internal NIC>? yes In this example we want to configure a static route to the 10.0.50.0/24 management network via the LAN gateway at 10.40.0.1. Network IP Address? 10.0.50.0/24 In this example the address is specified in CIDR format (thus you are not also prompted for a netmask). Via IP Address? 10.40.0.1 This is the LAN gateway address Add another custom network route for <internal NIC>? no In this example we only want to add one route. IP Address for external interface? 198.51.100.130 The IP address of the external interface of the appliance. Subnet mask for external interface? 255.255.255.128 The network mask for the external interface. Default gateway for external interface? 198.51.100.129 The address of the appliance's default gateway.
- Complete the remaining steps of the installation wizard as appropriate for your environment (see Running the installation wizard for a full list of the remaining installation wizard steps).
- After the install wizard completes, the reverse proxy/TURN server will reboot with the new configuration.
If you want to confirm that the eth0 and eth1 interfaces correspond with the correct port group in VMware:
- Log in to the reverse proxy/TURN server through SSH or VMware console as user 'pexip'.
This shows the hardware MAC addresses of each interface, so that these can be matched against the virtual interfaces in VMware.
If the reverse proxy/TURN server is deployed with a dual NIC public/private address, then Conferencing Nodes will typically not be able to discover their public NAT addresses as they will be sending their STUN requests to the internal interface of the TURN server.
Therefore, you will need to configure Pexip Infinity with a separate STUN server (see Configuring Pexip Infinity to use a STUN server).