Course13:IT Connect - 10.0 Reverse Proxy

From innovaphone wiki
Jump to navigation Jump to search

How to configure a Reverse Proxy

Reverse Proxy

The innovaphone Reverse Proxy (RP) is a service that accepts incoming TCP connections, inspects the content of the first packet and determines if and where to relay this connection to. The decision is based on the connection (e.g. port, certificates) and packet content. The service can run on any innovaphone gateway.

The main purpose of this service is to allow access for HTTP(s), LDAP(s), H323(TCP/TLS) and SIP(TCP/TLS) to the PBX and the App-Platform (needed mainly for myApps/IP-phones), but minimise the access only to some allowed URLs or domain-names.

This is needed if you want to allow remote devices like IP-phones or myApps-clients running in homeoffices or on mobile devices to connect to your PBX over the Internet.


The configuration can be separated in 4 main parts:
  1. Configure the RP service on a gateway
  2. Make the configured RP ports reachable through the customers Firewall/NAT-Router
  3. Configure public DNS – Names for your RP
  4. Load a certificate matching your DNS-name on the device running the RP
The rest of this chapter is a dry run. In other words, you can't really try it out in the course, mainly because you don't have access to an external DNS and it wouldn't be easy to call-in from outside the IP411RIGHT (which would be your reverse proxy).


The screenshot.png Reverse Proxies PbxManager plugin will allow you to screenshot.png add a Reverse Proxy. Similar to the Trunks plugin, you must now choose on which device/gateway your Proxy-Service will run. If you have multiple gateways to choose from, it is recommended to use a separate gateway than the one running the PBX – the resulting configuration will be simpler and easier to debug. Also, you don’t allow external access directly to your PBX – an attacker running a DoS attack on your RP will not affect telephony in general (running on the separate PBX).

After a gateway is selected, you must choose in the screenshot.png Settings section which of the 4 above mentioned TCP-services are needed and the port to use. H323 and LDAP should be enabled if IP-phones (e.g. homeoffices) will connect through the RP, HTTP is needed for myApps. SIP is needed only seldom, when 3rd party SIP-phones need to connect to the PBX – in most cases SIP can be left disabled. Even for use of a SIP trunk, SIP is usually not required in the reverse proxy.

The option screenshot.png Set Standard Ports (public IP) sets the default port numbers and is used if you run the reverse proxy on a separate device. However, this course focuses on small solutions that should be implementable with a single box. To avoid port conflicts with the PBX or HTTP server, standard ports shouldn’t be used. So do not tick this check-mark!

Next, we need to video2.png configure the hosts/domains that should be served on these ports. Here you should choose the suggested PBX ( and AP ( options. This will create all needed entries for IP-phone and myApps access to your PBX and AP-Platform.

Port Forwarding

In the last chapter we discussed that the reverse proxy will receive requests on non-standard ports and forwards them to the standard ports on your PBX or App platform. Your remote devices however will send their requests to the standard ports of your NAT router. As a result, you must configure your NAT router so that it forwards traffic on the standard ports to the respective non-standard ports your reverse proxy uses.

So the following port maps must be configured in the customers Internet-router or firewall:
  • TCP-Port 80 (HTTP) => RP IP address, port used on RP for HTTP (e.g. 90)
  • TCP-Port 443 (HTTPS) => RP IP address, port used on RP for HTTPS (e.g. 453)
  • TCP-Port 389 (LDAP) => RP IP address, port used on RP for LDAP (e.g. 399)
  • TCP-Port 636 (LDAPS) => RP IP address, port used on RP for LDAPS (e.g. 646)
  • TCP-Port 1720 (H323/TCP) => RP IP address, port used on RP for H323/TCP (e.g. 1730)
  • TCP-Port 1300 (H323/TLS) => RP IP address, port used on RP for H323/TLS (e.g. 1310)
  • TCP-Port 3478 (TURN/STUN) => RP IP address, port used on RP for TURN (usually also 3478)
  • UDP-Port 3478 (TURN/STUN) => RP IP address, port used on RP for TURN (usually also 3478)
  • ONLY IF 3rd party SIP-Phones are used: TCP-Port 5060 (SIP/TCP) => RP IP address, port used on RP for SIP/TCP (e.g. 5070)
  • ONLY IF 3rd party SIP-Phones are used: TCP-Port 5061 (SIP/TLS) => RP IP address, port used on RP for SIP/TLS (e.g. 5071)
(Further Hints) Some additional explanations on the 3478 port for STUN/TURN:

This is a service needed to pass audio/video data from external destinations (homeoffice, Internet) to internal devices. Such a TURN-server is automatically configured by the Install on your PBX, also the Install created the Devices Media provisioning category in Devices so that phones use this TURN server.

STUN/TURN is not handled by the reverse proxy but directly on your PBX. Therefore, STUN/TURN packets must be forwarded from the NAT router to the PBX whereas all other protocols are forwarded to your reverse proxy (which may or may not run on your PBX, depending on which device you selected when configuring the reverse proxy).


Now that you have taken care of the port forwarding from the Internet to your RP, you need to ensure that the DNS names that you already use internally for your PBX and AP-Platform (i.e. & are known at public DNS-servers and point to the external IP of your NAT-Router/Firewall.

You can check this using nslookup and a public DNS-server (e.g. For this open a command prompt (cmd.exe) on your PC and enter:

Non-authoritative answer:
Address: [your-external-IP-address]
Server: answer:Name: apps.dvl-ckl2.netAddress: [your-external-IP-address]


As all TLS-based external access to the PBX (H.323/TLS, SIPS. LDAPS, HTTPS) shall be routed through the RP and the RP terminates the TLS connections itself, the TLS clients will actually always see the RP's certificate as "server certificate". It is therefore sufficient if the clients have the RP's certificate in their own trust list.

The RP's certificate must therefore screenshot.png be valid for all the forwarded services. Practically, a wildcard service (like * is required to make certificate validation work.

Changing a Device Certificate

For certificates to work correctly with your browser without complaints, you will need to install proper certificates on your devices. This needs to be a full certificate that includes the private key (so keep it safe!).

You will recognize a "full" certificate by a part that reads like


You can add such certificate file screenshot.png using the Upload button in fish-help.png General/Certificates.

Creating a new Device Certificate

To create a new certificate for your device, you can screenshot.png create a signing request on this device in fish-help.png General/Certificates/Create new. You should keep the same CN but add one or more DNS Name or IP Address entries in the request.

Please keep in mind that the device certificate's key length greatly influences TLS performance (see fish-help.png Certificate management for details). We therefore recommend not to use certificates with key length of more than 1024 bits.

Your CA will issue a certificate based on the signing request.

Adding a new CA to your Browser's CA List

Your browser will use a list of known, trusted CAs. Some browsers use the operating system's CA list (Edge, Chrome), some have their own (Firefox).

Adding to Window's Trust List

You can add a certificate in to the Windows certificate store screenshot.png using the Install Certificate explorer context menu. You need to install it into the computer's storage for trusted CAs, so do not let windows choose the storage location.

screenshot.png Egde and screenshot.png Chrome will now accept the certificate.

Adding to Firefox's Trust List

Firefox however is using it's own trust list. You can do this by screenshot.png viewing the certificate list.

screenshot.png Firefox will now accept the certificate then.

Fixing the RP validation in the PBX

The PBX needs to identify requests that come via a reverse proxy. For this to work, the IP addresses of all known (more precisely, of up to 8) reverse proxies are configured in PBX/Config/General in the field Reverse Proxy Addresses.

For enhanced security, the validation can optionally be based not only on the RP's IP address but on the subject attribute found in the certificate it sends when establishing a TLS connection to the PBX. The value of this attribute (a.k.a. the name of the certificate) can be added to the IP address with a slash (e.g. In this example, the certificate's subject has to be 0090334106b5 (innovaphone devices use their own serial number as certificate subject).

The Reverse Proxy PbxManager plugin does this screenshot.png additional security configuration, so the certificate name will be validated too. However, once you have installed a new certificate with a new subject on the reverse proxy, this validation will fail. You need to screenshot.png fix the certificate name to make it work again.

Also, you will need to make sure that the PBX trusts the new RP's certificate (or its root certificate). See Allowing registrations from devices with no valid certificate in The individual Device User Interface for a discussion how to do that.

Firewall Settings

In real life, your PBX is protected by a firewall that controls all traffic to and from the PBX and all its devices. Specifically, the firewall will deny all related traffic unless it is specifically told to allow it.

For this reason, you will need to speak to the customer's firewall administrator. The information this administrator needs can be found in fish-help.png Firewall Settings.