Course13:IT Connect - 10.0 Reverse Proxy

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.

Configuration

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).

PbxManager

The  Reverse Proxies PbxManager plugin will allow you to  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  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  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  configure the hosts/domains that should be served on these ports. Here you should choose the suggested PBX (hq.dvl-ckl2.net) and AP (apps.dvl-ckl2.net) 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)

 

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).

DNS

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. hq.dvl-ckl2.net & apps.dvl-ckl2.net) 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. 8.8.8.8). For this open a command prompt (cmd.exe) on your PC and enter:

C:\>Users\ITC\nslookup Server: google-public-dns-a.google.com Address: 8.8.8.8 > hq.dvl-ckl2.net Server: google-public-dns-a.google.com Address: 8.8.8.8 Non-authoritative answer: Name: hq.dvl-ckl2.net.net Address: [your-external-IP-address] >apps.dvl-ckl2 Server: google-public-dns-a.google.comAddress: 8.8.8.8Non-authoritative answer:Name: apps.dvl-ckl2.netAddress: [your-external-IP-address]

Certificates

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  be valid for all the forwarded services. Practically, a wildcard service (like *.innovaphone.com) 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

-----BEGIN RSA PRIVATE KEY----
...
-----END RSA PRIVATE KEY----

You can add such certificate file  using the Upload button in  General/Certificates.

Creating a new Device Certificate

To create a new certificate for your device, you can  create a signing request on this device in  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  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  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.

 Egde and  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  viewing the certificate list.

 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. 172.30.226.3/0090334106b5). 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  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  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  Firewall Settings.