Considerations On Setting Up Pade Behind a Reverse Proxy

In this guide we will discuss how to set up Pade behind a reverse proxy. We will look at a single node and at a clustered setup and discuss the differences between the two. To be able to configure your collaboration server behind a reverse proxy you will first need to understand the traffic flows involved and adjust your environment accordingly. In the wiki we will discuss such flows and present a possible approach for this configuration.

Single Node

On a single node setup there is very little that needs to be done on the Openfire server. If you want to present the service as running on the well known tcp 443 port you will need to adjust the "WebSockets Data Channel" configuration as can be found on the networking section of the Pade plugin in openfire. On that section set the "Public port used for secure websockets data channel externally (client-to-server):" to 443. If you are presenting the service on port 7443 then you may leave this as is. If you do not want to expose any udp ports in your environment you will also need to adjust "Media traffic over TCP" section on the networking section of the Pade plugin in openfire. On that section set "Media traffic over TCP" to enabled and adjust the "Mapped port number:" according to your needs. If for example you want to present tcp 443 to the clients then change that port to 443. Please note that this setting may have an adverse impact on the quality of the video calls. This may be more noticable during screen shares that may default to very low resolution. To set up the Reverse proxy you will need to understand the urls that the service is advertising to clients. In your proxy configuration you will also need to account for the connection upgrade that is required for the CoLiBri websocket. Your proxy solution should also support the forwarding of udp packets. An open source proxy server that seems to work well with pade is Nginx. Nginx supports proxying of udp streams. To enable udp streams on the server you will need however, to install the relevant module if it does not come default with your installation. It is important to understand the flows that are involved in this service to be able to set up your equipment accordingly. The expected behavior is as follows: Users navigate to the url that you have advertised as offering access to the pade service. For the sake of this example let's assume that this url is pade.domain.com. Once the appropriate room is defined and the user is authenticated the browser will be instructed to create a websocket chanel with the service. This is exposed with a url of pade.domain.com/colibri-ws/ the browser will also attempt to verify availability of the service by attempting connections to a url like pade.domain.com/ws/?room=your_room. This response will need to come back with a 200 ok. The service will present the public address of the Jitsi Video Bridge instance to the browser this will need to be a routable address like 1.1.1.1 which will be the public address of your udp proxy. The port that the browser gets instructed to is udp 10000. In your openfire pade settings you might need to define this public ip in the "IP Address Mapping" section within the network settings. On this section you might need to define a Local Address which will be the local address of your openfire instance i.e. 192.168.1.1 and a Public Address which will be the routable ip address of your load balancer that listens on port udp 10000 in our case 1.1.1.1 This may not be required for a single node setup since Pade will pick up these settings automatically. Assuming a scenario where you want to present this service to your users on the url pade.domain.com the below configuration should work well for tcp traffic: `upstream Pade_7443{ server 192.168.1.1:7443; }

server { listen 443 ssl; server_name pade.domain.com; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_ssl_verify off; location /colibri-ws/ { proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_pass https://Pade_7443/colibri-ws/; } location /ws/ { proxy_pass https://Pade_7443/ws/; } location /http-bind/ { proxy_pass https://Pade_7443/http-bind/; } location / { proxy_pass https://Pade_7443/ofmeet/; } }` The above settings assume that your openfire server has an ip of 192.168.1.1 and is accessible to the reverse proxy on that ip. As can be seen from the configuration we are instructing the proxy to perform the following translations:

• requests going to "pade.domain.com/colibri-ws/" will be upgraded to websockets and be forwarded to "https:/192.168.1.1:7443/colibri-ws/"
• requests going to "pade.domain.com/ws/" will be forwarded to "https:/192.168.1.1:7443/ws/" with these requests the client browser will be looking for a 200 ok response to verify the room is available.
• requests going to "pade.domain.com/http-bind/" will be forwarded to "https:/192.168.1.1:7443/http-bind/" this is required for BOSH.
• requests at "pade.domain.com" will be forwarded to "https:/192.168.1.1:7443/ofmeet". If you also want to proxy UDP traffic you can use something like this in your stream configuration of the service: `upstream PadeConferencing{ server 192.168.1.1:10000; }

server { listen 10000 udp; proxy_pass PadeConferencing; }` If you do not want to use UDP traffic you may skip the streams configuration.

Clustered Pade