Pexip Infinity Reverse Proxy Deployment Guide

Transcription

1 Pexip Infinity Reverse Proxy Deployment Guide Introduction About the Pexip App and reverse proxies The Pexip App for mobile devices such as ios phones and tablets enables conference participants to extend the conferencing experience to their personal device. It gives them interactive access to conference roster lists and presentation streams, as well as the ability to add, remove and mute participants while the conference is in progress. The Pexip App uses a RESTful API to communicate with one or more Conferencing Nodes. If they are located in a private enterprisetype network, these Conferencing Nodes will normally not be accessible for mobile devices located in public networks such as the Internet. However, deploying a reverse web proxy in the enterprise DMZ will allow devices running the Pexip App to securely and reliably communicate with the Conferencing Nodes, because the reverse proxy will form a bridge between the externally-located mobile devices and the internally-located Conferencing Nodes. This means that the reverse proxy will normally have two network interfaces: one connected to the external network and having a publicly routable IP address; and another connected to the internal network and having a private IP address, which can communicate with the Conferencing Nodes. In deployments with more than one Conferencing Node, the reverse proxy can load-balance between the various Conferencing Nodes in a round-robin fashion. A reverse proxy can also provide an authentication layer between the Pexip App and Conferencing Nodes, for instance by using LDAP queries towards Active Directory Pexip AS Version 1.a October 2013 Page 1 of 18

2 About this guide In addition to providing general Reverse proxy guidelines and principles, this guide describes two specific methods of deploying a reverse proxy: by installing the pre-configured reverse proxy provided by Pexip in the form of an OVA template suitable for deployment as a virtual machine on VMware ESXi by using an HTTP reverse proxy server - here we use nginx as an example of how such a server should be configured. Both these sections make reference to the Example deployment used throughout this document. Prerequisites The Pexip Infinity deployment (i.e. a Management Node and at least one Conferencing Node) must be configured and in a working state. For full information and instructions see the Pexip Infinity Administrator Guide. Appropriate DNS SRV records have been created in accordance with the Reverse proxy guidelines and principles. Example deployment Diagram showing example deployment used in this guide The diagram above depicts the example deployment which will form the basis of this deployment guide. The environment is split into three parts - two geographic location network segments (Europe and US) and one DMZ perimeter network. Each geographic location has one Pexip Infinity Conferencing Node, while the DMZ perimeter network contains the reverse proxy application Pexip AS Version 1.a October 2013 Page 2 of 18

3 The example network deployment is set up such that there is regular IP routing between the DMZ network and the internal geographic network segments, where traffic is controlled by one or more firewalls (not shown in the above diagram) that are located between the different parts of the network. The reverse proxy located in the DMZ network has two network interfaces: an externally-facing interface (IP address ) which is connected to the DMZ outside/public network (Internet) an internally-facing interface (IP address ) which is connected to the DMZ internal/private network. There is no IP routing between the outside and inside DMZ network segments. However, the reverse proxy will enable external Pexip App clients to communicate with the internal Conferencing Nodes because it will create the required "pathway" between the outside world and the internal Conferencing Nodes. Each geographic location has one Conferencing Node, which are both managed by the same Management Node. This means that if user Alice enters the virtual meeting room on the node located in Europe, and user Bob enters the same virtual meeting room on the node located in the US, these two meeting room instances will automatically be joined together by the virtual backplane between the two nodes, so that Alice and Bob are part of the same conference. Reverse proxy guidelines and principles The Pexip App works by sending HTTP GET and POST requests to a certain destination address in order to fetch information about a meeting (for instance the roster list) and to send various commands (for instance to mute or remove conference participants). The destination address used for sending the HTTP requests is automatically discovered through a custom DNS SRV lookup for _pexapp._tcp.<domain>. For instance, if the Pexip App has been pre-configured with a meeting URI of [email protected], it will perform a DNS SRV lookup for _pexapp._tcp.example.com. In our example deployment, the _pexapp._tcp.example.com DNS SRV record has already been created and points to the DNS A-record proxy.example.com, port 443 (HTTPS), with a priority of 1 and a weight of 100, as follows: _pexapp._tcp.example.com IN SRV proxy.example.com. This way, the Pexip App knows that it should be sending its HTTP requests to host proxy.example.com (our reverse proxy server) on TCP port 443. If the Pexip App is unable to locate the reverse proxy through DNS SRV discovery because either: the SRV lookup on _pexapp._tcp.example.com does not return any records, or the Pexip App cannot contact the first host on the list that is returned in the SRV lookup, it will fall back to performing a DNS A-record lookup for the domain in question. If successful, it will attempt to connect to port 443 on the IP address returned from this A-record lookup. As an example, assume that users Alice and Bob enter the virtual meeting room [email protected] on the US Conferencing Node. Without a reverse proxy in place, and assuming the device running the Pexip App has IP connectivity with the Conferencing Node,if the Pexip App now sends an HTTP GET request directly to the US Conferencing Node (to fetch the roster list for the meeting), the US Conferencing Node would return a success response (200 OK) containing the roster list. If the Pexip App however sends the same HTTP GET request to the Europe Conferencing Node (also without a reverse proxy in place), the Europe Conferencing Node would return a failure response (404 Not Found), since this node currently does not have any attendees for the conference in question. When implementing a reverse proxy in this example deployment, the following key principles apply: 2013 Pexip AS Version 1.a October 2013 Page 3 of 18

4 In theory, any reverse proxy may be deployed and used if it is capable of adhering to the behavior described in the points below. The reverse proxy should be configured with all Conferencing Nodes as backend/upstream servers, with equally-weighted round-robin load balancing towards these servers. When a backend/upstream server (Conferencing Node) returns HTTP code '404 Not Found' for a GET/POST request sent by the Pexip App, the reverse proxy should forward the original request to the next available server until a successful response (200 OK) is received, unless all upstream servers return a 404 response, in which case the reverse proxy should send the final 404 response back to the Pexip App. If desired, the reverse proxy can be configured to challenge Pexip App clients for basic HTTP authentication as they send HTTP requests, for example via an LDAP/AD backend. With these key principles applied, and assuming that: Alice and Bob are joined to virtual meeting room [email protected] on the US node, and no users are currently joined to this virtual meeting room on the Europe node, the following would take place when an externally located Pexip App client configures a meeting URI of [email protected]: 1. The Pexip App performs a DNS SRV lookup for _pexapp._tcp.example.com and discovers proxy.example.com as the reverse proxy for this domain. 2. The Pexip App sends a HTTP GET request to proxy.example.com. 3. The reverse proxy receives the HTTP GET request and randomly chooses to forward this request to the Europe Conferencing Node. 4. The Europe Conferencing Node returns a '404 Not Found' response as there aren't any attendees for this virtual meeting room on this node. 5. The reverse proxy continues by forwarding the original request to the next backend/upstream server, which in this case is the US Conferencing Node. 6. The US Conferencing Node returns a '200 OK' response containing the requested data, because the virtual meeting room on this node had two attendees, namely Alice and Bob. 7. The reverse proxy forwards the '200 OK' response back to the Pexip App, which successfully displays the roster list for the virtual meeting room. The Pexip App will keep polling the reverse proxy periodically in order to update the roster list for a given virtual meeting room for as long as the application is active. Access for internally located Pexip App clients In the examples used in this document, the reverse proxy is configured to listen for incoming connections from Pexip App clients on both the external and internal interfaces. This enables the reverse proxy to be used for Pexip App clients which are located inside the enterprise network also. In order for these clients to communicate with Conferencing Nodes through the internal interface, DNS resolution for these internal clients has to be configured so that DNS SRV and A-record lookups for _pexapp._tcp.example.com and proxy.example.com respectively resolve to the internal interface address of the reverse proxy, e.g This behavior, where DNS records resolve differently when looked up from the internal side of the network, is also referred to as Split horizon DNS or simply Split DNS. If the reverse proxy will only be serving externally located Pexip App clients, the reverse proxy does not need to be configured to listen for incoming HTTPS connections on the internal interface Pexip AS Version 1.a October 2013 Page 4 of 18

5 Security considerations The Pexip App will by default use encrypted HTTPS when communicating with a reverse proxy. We strongly recommend using encrypted HTTPS communication between the Pexip App and the reverse proxy. Unencrypted HTTP communication is only intended to be used for debugging purposes. When configured correctly, the reverse proxy will allow HTTP/HTTPS traffic to flow between the Pexip App and the internal Conferencing Nodes only. Externally located clients will not be able to access other internal resources through the reverse proxy. We recommend that you install your own SSL/TLS certificates on the reverse proxy for maximum security. Deploying the reverse proxy using an OVA template Pexip provides a pre-configured reverse proxy installation via an OVA template suitable for deployment on VMware ESXi. This OVA template is provided as-is and provides a reference installation which will be suitable for typical Pexip deployments where: Conferencing Nodes are deployed in internal, private networks the reverse proxy is typically deployed in a DMZ environment using one or two network interfaces. Assumptions The configuration example in this section will assume the example deployment described in Example deployment, with the following additional assumptions: The externally-facing interface ( ) resides in the same subnet as the default gateway, which has an IP address of The internally-facing interface ( ) resides in the same subnet as a router with IP address Router is the next hop when accessing all internal hosts in Europe and US. The internal networks are defined by CIDR /8 ( ). Hosts residing in the internal network /24 will be used when accessing the reverse proxy over SSH. Deployment steps Downloading the OVA template Download the OVA template from to the PC running the vsphere client. Either the vsphere desktop client or web client can be used. Deploying the OVA template To deploy the OVA template using the vsphere desktop client for Windows, select File > Deploy OVF template. You will be prompted to browse for the OVA file (see screenshot below). Select Next and follow the on-screen prompts. To deploy the OVA template using the vsphere web client, right-click on the host and select Deploy OVF template Pexip AS Version 1.a October 2013 Page 5 of 18

6 Screenshot of the Deploy OVA Template window when using the vsphere desktop client After the OVA template has been deployed, power on the newly-created virtual machine. Resetting the password After the virtual machine has fully started, open the console of the virtual machine. A login prompt will appear as shown in the upper section of the screenshot below Pexip AS Version 1.a October 2013 Page 6 of 18

7 Screenshot showing the initial login prompt and install wizard prompt Before you can start the install wizard, you must change the password. To do this, log in as user pexip with password PEXIPTEMP (these are case sensitive). You will be prompted to set a new account password. To do this you must re-enter the current PEXIPTEMP password, and then enter the new password twice. After a new password has been set, the Pexip Reverse Proxy banner will be shown, and you will be prompted to enter the new password. After this password has been entered, the install wizard will commence Pexip AS Version 1.a October 2013 Page 7 of 18

8 Running the Installation Wizard The install wizard is divided into several steps, which are explained in detail below. Some steps require a single line of input, while some steps allow multiple lines of input to be entered, one line at a time. Some steps also allow multiple entries on the same line. As mentioned previously, the input examples used below assume a deployment as described in Example deployment on page 2, in addition to the Assumptions described above. The table below shows, for each step, the prompt text that will be shown, the text you should input, and an explanation of the step. Step Prompt text Input Explanation 1 Number of network interfaces (1 or 2): 2 In this deployment, the reverse proxy will use two network interfaces. 2 Choose externally facing interface (Or active interface if using single interface): 0: eth0 (Mac address: 00:50:56:a9:dd:ee) 1: eth1 (Mac address: 00:50:56:a9:5a:05) Choose interface: 1 When using two network interfaces, eth1 should always be chosen as the externally facing interface. For this selection, the MAC addresses of the virtual interfaces are shown, to ensure that you can correctly identify the interfaces and ensure that they are configured with the correct port group in VMware. 3 IP address - external/active interface: is the IP address that we have chosen for the external reverse proxy interface. 4 Network mask - external/active interface: In this example deployment, the externally facing interface has a network mask of ( /24 in CIDR notation). 5 Default gateway: The default gateway in this deployment is a router/firewall with IP address , residing on the same network segment as the externally facing interface. All network traffic from the reverse proxy will by default be routed via this host, unless the traffic in question matches a static network route (configured at a later point) Pexip AS Version 1.a October 2013 Page 8 of 18

9 Step Prompt text Input Explanation 6 IP address - Internal interface: is the IP address that has been chosen for the internal reverse proxy interface. 7 Network mask - Internal interface: In this example deployment, the internally facing interface has a network mask of ( /24 in CIDR notation) Pexip AS Version 1.a October 2013 Page 9 of 18

10 Step Prompt text Input Explanation 8 Enter network address and subnet mask of network/host allowed to access this host over SSH, followed by [ENTER]. [Network/host address] [Network mask] Example: (Allow SSH access for host /32) (Allow SSH access for network /24) (Allow SSH access for ALL hosts) NOTE: SSH access will only be applied to the internal/active interface. Press [ENTER] on an empty line to finish entering management networks: 9 Enter network(s) to be statically routed. [Network address] [Network mask] [Gateway address] Example: [ENTER] [ENTER] Press [ENTER] on an empty line to finish entering routes: [ENTER] [ENTER] Hosts residing in the internal network /24 will be used when accessing the reverse proxy over SSH. This access is controlled by the iptables firewall on the reverse proxy. This step accepts multiple lines of input, one at a time. In this example deployment, all internal hosts (10.x.x.x) are accessible via router , which resides on the same network segment as the internally facing network interface. This step accepts multiple lines of input, one at a time Pexip AS Version 1.a October 2013 Page 10 of 18

11 Step Prompt text Input Explanation 10 Hostname: proxy In this example deployment, the reverse proxy has a hostname of proxy. It is important that the hostname and domain (configured in the next step) matches the actual DNS name which the reverse proxy will be addressed by (in our example this is proxy.example.com. This also means that if a replacement SSL certificate is to be created for this reverse proxy, the Subject Name and Subject Alternate Name of this certificate also needs to match the configured host name and domain name of the reverse proxy. For more information, see Running the Installation Wizard. 11 Domain suffix: example.com In this example deployment, the reverse proxy has a domain name/suffix of example.com. This means, since the host name in the previous step was configured as proxy, that the full FQDN of this reverse proxy is proxy.example.com. For a custom SSL certificate, this FQDN needs to match the Subject Name and Subject Alternate Name of the SSL certificate. 12 DNS server(s), space separated: NTP server(s), space separated: 0.no.pool.ntp.org 1.no.pool.ntp.org 2.no.pool.ntp.org In this example deployment, the reverse proxy is configured to use DNS servers and DNS is in this case mainly used to resolve the hostnames of NTP servers. In this example deployment, the reverse proxy is configured to use three different pools of NTP servers, to ensure proper NTP time synchronization. 14 Enter IP address of each conference node separately, followed by [ENTER]. Press [ENTER] on an empty line to finish entering conference nodes: Enter IP of next conference node or press [ENTER] if finished: [ENTER] [ENTER] [ENTER] In this and the following step, the IP addresses of both Pexip Conferencing Nodes are input, one at a time is the US conference node (us-conf-01-example.com) while is the EU conference node (eu-conf- 01.example.com). If the example deployment had additional conference node in either location, the IP addresses of these nodes should also be input in this step Pexip AS Version 1.a October 2013 Page 11 of 18

12 When all install wizard steps have completed, the reverse proxy will automatically reboot. After the reverse proxy has started up again it will be ready for use - Pexip App users will now be able to access Virtual Meeting Rooms from outside your network Pexip AS Version 1.a October 2013 Page 12 of 18

13 Restoring the reverse proxy to its default state If you need to re-run the install wizard (for instance if additional conferencing nodes have been added to the environment and therefore should be included in the reverse proxy configuration), you must first reset the reverse proxy to its original default state. To do this: 1. Open the console of the virtual machine (or otherwise log in via SSH). 2. Log in as user pexip. 3. Run the following command: sudo reset_to_default_settings 4. You will be presented with a warning asking if you wish to continue. Enter y. 5. You will be asked whether you wish to delete or keep the log files which exist on the reverse proxy. Enter y or n as appropriate. 6. You will be asked whether you wish to reboot the virtual machine. Enter y. After the reverse proxy has rebooted and restarted, you can re-run the install wizard by logging in as user pexip with password PEXIPTEMP and following the steps in the section Running the Installation Wizard. Replacing the default SSL certificate If you wish to replace the built-in X.509 SSL certificate on the reverse proxy with a custom-created certificate, the following procedure should be performed: 1. Create a file called pexip.pem which contains both the server certificate as well as the private key for the server certificate, so that the bundled file contains both a section with ---- BEGIN PRIVATE KEY ---- / ---- END PRIVATE KEY ---- as well as a section containing BEGIN SERVER CERTIFICATE ---- / END SERVER CERTIFICATE Using the SCP file transfer protocol, upload the pexip.pem file to the /tmp folder of the reverse proxy. This can be done using for instance WinSCP ( or the scp command-line utility for Linux/Mac OS X, using a command such as: scp pexip.pem pexip@ :/tmp 3. After the pexip.pem file has been transferred into the /tmp folder of the reverse proxy, SSH to the reverse proxy, log in as user pexip and run the following commands, one at a time: sudo cp /etc/nginx/ssl/pexip.pem /etc/nginx/ssl/pexip.pem.backup sudo mv /tmp/pexip.pem /etc/nginx/ssl/pexip.pem sudo service nginx restart After these two commands have been run, the reverse proxy should now be operational and using the new certificate. If any problem occurs with the replaced certificate, the previous certificate can be restored using the following commands: sudo cp /etc/nginx/ssl/pexip.pem.backup /etc/nginx/ssl/pexip.pem sudo service nginx restart 2013 Pexip AS Version 1.a October 2013 Page 13 of 18

14 Enabling LDAP/AD authentication (for advanced users) The reverse proxy supports remote LDAP/AD authentication, meaning that the Pexip App will have to be configured with a username and password (in Connection Settings) to allow the Pexip App to communicate with the reverse proxy. In order to enable LDAP/AD authentication, certain changes need to be performed in the configuration file /etc/nginx/sitesenables/pexapp. This file contains two configuration sections related to LDAP/AD authentication, as follows: #ldap_server ldapserver { # url ldap:// :3268/dc=test,dc=local?samaccountname?sub?(objectclass=person); # binddn "TEST\LDAPUSER"; # binddn_passwd LDAPPASSWORD; # group_attribute uniquemember; # group_attribute_is_dn on; # require valid_user; #} and # Uncomment the next two lines to enable LDAP/AD authentication for pexapp # # NOTE: Also make sure to uncomment and configure the 'ldap_server' section # further up in the config file when enabling LDAP/AD auth here #auth_ldap "Restricted area"; #auth_ldap_servers ldapserver; Syntax explained url ldap:// :3268/dc=test,dc=local?samaccountname?sub?(objectclass=person); This configuration line defines that the LDAP/AD server has an IP address of , using port The search scope is DC=test,DC=local, and that the username provided by the Pexip App is matched against the samaccoundname attribute in LDAP/AD. binddn "TEST\LDAPUSER"; This is the user/service account which the reverse proxy will use when binding to LDAP/AD. The relevant parts of the configuration need to be changed to reflect the values required for the LDAP/AD server which is to be used. binddn_passwd LDAPPASSWORD; This is the password for the bind user, entered in clear text. In order to enable LDAP/AD authentication, these two configuration sections need to be uncommented, meaning that the leading hash (#) symbol in front of the respective lines need to be removed, so that the resulting sections appear as follows in the configuration file (do not uncomment the actual comment explanation lines themselves): ldap_server ldapserver { url ldap:// :3268/dc=test,dc=local?samaccountname?sub?(objectclass=person); binddn "TEST\LDAPUSER"; binddn_passwd LDAPPASSWORD; group_attribute uniquemember; group_attribute_is_dn on; require valid_user; } and 2013 Pexip AS Version 1.a October 2013 Page 14 of 18

15 # Uncomment the next two lines to enable LDAP/AD authentication for pexapp # # NOTE: Also make sure to uncomment and configure the 'ldap_server' section # further up in the config file when enabling LDAP/AD auth here auth_ldap "Restricted area"; auth_ldap_servers ldapserver; In order to perform the required changes to the configuration file, run the following commands from the SSH shell of the reverse proxy: sudo cp /etc/nginx/sites-available/pexapp /etc/nginx/sites-available/pexapp.backup sudo nano /etc/nginx/sites-available/pexapp Perform the required configuration changes. After you have finished, press Control + O to save the changes, ENTER to confirm and Control + X to exit the editor. sudo service nginx restart If the reverse proxy service does not start up after editing, the following commands will restore the original configuration file: sudo cp /etc/nginx/sites-available/pexapp.backup /etc/nginx/sites-available/pexapp sudo service nginx restart Reference configuration using nginx As mentioned earlier in this document, the Pexip App does not require a particular type of reverse proxy, but the reverse proxy in use must support and adhere to the key features mentioned in Reverse proxy guidelines and principles. One such reverse proxy is nginx ( an open source HTTP and reverse proxy server. In this section, a simple reference configuration for nginx will be described. This contains: a basic set of configuration which allows the reverse proxy to operate correctly LDAP authentication settings for authenticating the Pexip App against an LDAP/AD backend. These settings are by default disabled (they have been commented out in the reference configuration). The LDAP authentication functionality requires that nginx includes a third party module responsible for the LDAP authentication itself, this is explained in more detail inside the configuration file itself. This reference configuration is intended to be used as basic starting points and as a principal guideline for an nginx reverse proxy configuration. The configuration should be treated as an example rather than a complete and finished configuration, as configuration needs and requirements will vary from one deployment to another. This section will not cover initial installation of nginx itself, but rather show the site-specific configuration for the Pexip App reverse proxy. For an in-depth explanation of all available configuration parameters, please refer to Pexip AS Version 1.a October 2013 Page 15 of 18

16 Reference configuration # Conference nodes ( and ) upstream pexip { server :443 weight=1 max_fails=2 fail_timeout=30s; server :443 weight=1 max_fails=2 fail_timeout=30s; keepalive 2048; } # LDAP authentication - This requires nginx to be compiled with module 'nginx-auth-ldap' # See for more info # # Uncomment the following section to define an LDAP/AD backend for authentication # replacing the relevant values to fit your environment # # NOTE: Also make sure to uncomment the relevant two lines in the 'location' # section below when defining the LDAP/AD backend #ldap_server ldapserver { # url ldap:// :3268/dc=test,dc=local?samaccountname?sub?(objectclass=person); # binddn "TEST\\LDAPUSER"; # binddn_passwd LDAPPASSWORD; # group_attribute uniquemember; # group_attribute_is_dn on; # require valid_user; #} server { listen 443 ssl; server_name proxy.example.com; ssl_certificate ssl/pexip.pem; ssl_certificate_key ssl/pexip.pem; ssl_session_timeout 5m; ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!DH:!EDH; ssl_prefer_server_ciphers on; access_log /var/log/nginx/pexapp.access.log; error_log /var/log/nginx/pexapp.error.log; error_page 404 /404.html; error_page /50x.html; location / { return 444; } location /api { proxy_next_upstream http_404 http_500 http_502 http_503 http_504 error timeout; proxy_pass proxy_redirect off; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_connect_timeout 2s; # Uncomment the next two lines to enable LDAP/AD authentication for pexapp 2013 Pexip AS Version 1.a October 2013 Page 16 of 18

17 } # # NOTE: Also make sure to uncomment and configure the 'ldap_server' section # further up in the config file when enabling LDAP/AD auth here #auth_ldap "Restricted area"; #auth_ldap_servers ldapserver; location = /favicon.ico { empty_gif; access_log off; } location /404.html { root /var/www; } } location /50x.html { root /var/www; } The above configuration reflects the example deployment depicted previously in this document. The reverse proxy listens for incoming HTTPS connections on both the external and internal interface on TCP port Pexip AS Version 1.a October 2013 Page 17 of 18

18 Appendix 1 Firewall ports The following ports have to be allowed through any firewalls which carry traffic for the involved devices: From Pexip App clients to reverse proxy: Description Source Destination HTTPS traffic inbound to reverse proxy <Any> 443 TCP From reverse proxy to Conferencing Nodes: Description Source Destination HTTPS traffic <Any> 443 TCP 2013 Pexip AS Version 1.a October 2013 Page 18 of 18