Course12:Advanced - Reverse Proxy
This book explains how to provide public access to PBX
- the services must be technically accessible in the given network setup.
Here, most notably firewalls and NAT create problems
- the systems security level needs to be maintained.
Although many attacks to IT systems origin from within the organizations, opening up access from the internet creates a whole lot of new issues
In this book, we will discuss how to address these issues. When we use the term "public access" it refers to clients accessing the PBX from anywhere including places in the internet (such as public hot spots) or from within foreign private networks.
Media and NAT
Media data (voice) however is exchanged directly between the involved endpoints. One of the big issues with VoIP communication across private network boundaries is the successful transmission of media data. In many scenarios, RTP data is not transmitted correctly - resulting in so-called "one-way" audio issues.
To understand this problem and the approaches to fix it, let us have a look at a simple scenario. We have a PBX with 2 phones in a LAN.
During call setup, Phone A will send its own IP address to the PBX, which will in turn send it to Phone B. Phone B will answer with its own IP address. In the end, both phones know their respective peer's IP address and can send RTP data.
Fair enough. Now let's think Phone A is calling a destination in the PSTN instead. Again, Phone A will send its own IP address to the PBX, which will in turn send it to the SIP Provider Call Server which will send it to the SIP Provider Media Gateway. The SIP Provider Media Gateway will answer with its own IP address. Unfortunately, in the end, the phone and the media gateway still know their respective peer's IP address, but can not send RTP data.
Both the Provider Call Server and the SIP Provider Media Gateway obviously are meant to be publicly accessible. The private PBX and phones of course are not. For this reason, they live in a private network, with private IP addresses not available from the internet. Although Phone A sends its own (private) IP address to the SIP Provider Media Gateway, and this gateway then sends its RTP data to this IP address, the data will never arrive at Phone A. Phone A however will send its RTP data to the public IP address of the SIP Provider Media Gateway and this will succeed. So we end up in one-way audio.
We will look at some approaches to fix this issue in the next chapters.
The answer is two folded.
First of all, the Router in our scenario employs a technique known as Network Address Translation (NAT). Put simply, here is how it works:
- the PC sends an IP packet (an HTTP GET REQUEST in this case) to the Server
- the packet is sent to the Router which forwards it to the internet. However, it replaces the IP packets source address (which is the private IP address of the PC) with its own public IP address
- the router keeps track of this process (it remembers a NAT mapping)
- the IP packet arrives at the server
- the server sends its response to the source address received in the previous request packet (note that the PC not even tries to send its own IP address to the server)
- the response IP packet returns back to the router
- the router sees a packet sent to himself (remember, the server has sent the packet to the source address of the request packet and that had been replaced by the router with his own public IP address)
- of course, the router has no real use for the packet. Fortunately, as it had kept a record of the previously allocated NAT mapping, it knows where the original request for this server came from. So it replaces the destination address of the response (which is currently its own public IP address) with the remembered private IP address of the PC and forwards it to the private network
- the response arrives at the PC
So this is how NAT works.And why is the answer two-folded?
Well, it works because the server does not send the response to an IP address it has been told by the PC as part of the original request. It simply returned the response to the address where the request came from (as seen by the server).
This is known as NAT Detection and works quite simple. Whenever the SIP Provider Media Gateway receives an RTP packet from the phone, it examines the IP source address of this packet and adjusts the IP address it sends its own RTP packets to accordingly. Effectively, as soon as the first RTP packet arrives, the gateway starts sending its own RTP to the public IP address of the router (remember that the router had replaced the RTP packet's IP source address with its own public IP address).
Private to Private Communication
Unfortunately, this only works if one end of the conversation has a public IP address. Let us have a look at a slightly more complicated scenario: an IP phone calls another IP phone in a different private network (this is known as on-net call).
In this scenario, Phone A and Phone C will again send their own private IP addresses to their peers. Neither Phone A nor Phone C are now able to send an RTP packet to the other end. Therefore, the NAT Detection technique does not work. We end up with no media.
For this to work, they need to find out the public IP address of their own internet router. You may think, well, then let's simply configure it to the phones. Putting the administrative effort aside, this is is not an option. You may want to review how NAT works. Somewhere in the process, the NAT router needs to keep track of the outgoing, mapped IP packet so it can forward the returning response to the proper internal device. When the RTP packet would be sent to the remote internet router, this router wouldn't know where to forward it.
This is fixed by use of a STUN server.
The STUN server has a public IP address (it is usually run by your internet provider) and can be reached easily by both phones (in fact, both phones could have their own STUN server, doesn't make a difference).
The STUN client (i.e. the phones) will send a request to the STUN server asking which source IP address do you see in my request? The server simply reports back the IP source address it has seen in the request packet (which is the public IP address of the calling client's internet router). This way, the phones learn their own external IP address which they then can send to their communication peers. At the same time, the STUN request has created a NAT map on the internet router. This map - which is intended by the router to map responses from the STUN server - is subsequently used by the remote peer to send its RTP packets to, which are then forwarded to the correct phone.
You might have smelled it, this STUN trick rather is an abuse of the NAT mechanism. After all, the router creates a NAT map so that the internal client (the phone) can communicate to the STUN server. However, the map is later used to facilitate communication to somebody else - the remote phone.
You guessed it, this is looking for trouble. In fact, there are various more or less restrictive NAT implementations. Some don't bother and let the 2 phones communicate. Others however detect the abuse and block it. The phones again end up in a no- or one-way audio situation.
In order for STUN based communication to work, at least one of the two routers performing NAT in a conversation must support full-cone or restricted NAT.
NAT Router Setup
In this scenario, if the Main Router supports full cone NAT, Phone A can talk to both Phone B and Phone C, as the Main Router supports full-cone NAT. However, for Phone B talk to Phone C, one of the Branch Routers must also support full-cone NAT.
To support any-to-any communication, all of the routers must support full-cone or restricted NAT thus.
An innovaphone device can detect the NAT type of the router used if you provide it with the address of a STUN server.
If none of the involved routers support full cone NAT, it might still work.
Full-cone, restricted- and port-restricted will work in any combination. However, if one end does symmetric NAT it will work only if the other side does full-cone or restricted NAT.
Multiple STUN Servers
It is possible to configure multiple STUN servers. The idea here is that all those servers are redundant, that is, they will return the same external address. All servers will be tried in parallel and the first one returning an answer will win.
If you use the ip-address[:port]] notation, you can specify 2 redundant servers separated by comma (e.g.
172.16.13.1:1234,172.16.13.2). If you use a single domain name, the DNS record may resolve to multiple IP addresses, which are executed in parallel. Multiple domain names for redundant STUN servers are not supported.
Multiple NATed Networks
In rare cases, an endpoint may need to communicate with its peer via different NATed networks, depending on who it is communicating with. An example could be a user who uses his normal internet router to communicate to mobile workers. However, there may be a second corporate branch network which is connected via another NAT router only.
In this case, the user has 2 possible STUN addresses: the external address of the internet router and the other side of his corporate NAT router.
This is why you can define 2 logically STUN servers (see
Note that this is not for redundancy (for this, see Multiple STUN Servers above). It defines two logical STUN servers which will both be queried for external addresses. Each of them however can be redundant (you would then end up with something like e.g.
Using the built-in STUN Server
If an innovaphone box is used as internet router, it can be used as STUN server. This function must be enabled in
If this has been done, both STUN clients from external (through the internet) and intern (from your own private network) can use the box as STUN server to learn their own public IP address and port map.
As the full name Traversal Using Relays around NAT suggests, the idea here is to relay media data through an entity (the TURN server) such that the media safely can traverse NAT boundaries.
One of the issues with the STUN solution we discussed before was that the NAT map created when querying the STUN server was later misused to relay RTP media through the NAT router (which may or may not work, depending on the router implementation).
The solution is that a TURN server is installed. All clients would
- contact the TURN server prior to the call
- thereby open a NAT map towards the TURN server
- send and receive their own media to/from the TURN server (tunnelled within the connection to the TURN server)
The TURN server would
- send/receive the (unpacked) RTP data on behalf of its client
The TURN server acts like a normal RTP endpoint on behalf of the respective client phone. The RTP flow would be as follows:
- Phone A crafts an RTP packet for Phone C
- the message is sent as RTP to the TURN server
- this TURN server would receive the RTP and package it in to a TURN message
- it sends this message to Phone C through the TURN connection (note that this may use UDP or TCP)
If you like, the TURN server is a buddy you can say to Hey, I've got a bad network connection where my peer cannot reach me. Could you lend me yours for a call? And the TURN buddy would do.
It is possible that both sides of the the call needs to use a TURN server. Also, both phones can use the same TURN server.
Note that SIP providers usually do NOT provide a TURN server (as this is a costly resource that requires both CPU and bandwidth and it is not needed for SIP trunk operation as we have seen). You will need to provide it yourself most probably. However, hosted PBX providers usually will provide it, as their service requires it.
TURN and RTP Ports
Please note that the RTP port offered by a TURN server to its client is under control of the TURN server. In other words, the RTP Port Range configured on the device using TURN is irrelevant. The RTP port is of course allocated by the TURN server and hence the setting on this TURN server is relevant.
For example, although the myPBX launcher would use ports in the range 60000+ for video RTP locally, its TURN server might offer ports in the 16384+ range. Effectively, video RTP data would then be sent to such port.
Internal TURN Server
You may now ask yourself how could I provide TURN services, this is asked too much of my local IT!? Surprisingly enough it is rather simple. Even if you have no possibility to provide a server which is located in the internet, it is possible.
The key is that the TURN protocol is available based on TCP. This way, you can provide a TURN server that actually sits in your local network just like you would provide a Web server. You simply configure a static NAT map in your internet router that points towards your TURN server.
The innovaphone PBX itself includes a TURN server implementation. So we can simplify the setup even more.
Note that a TURN server needs to establish RTP ports. This is why on any box that runs a TURN server, UDP-RTP ports need to be configured in IP4/General/Settings. Fortunately, the default configuration already allows for plenty of them.
While we are at that: note that if the box also runs as NAT router, you need to provide enough UDP-NAT ports also.
NB: while TURN works with UDP and TCP by design, innovaphone phones will use TURN/UDP only as of v12r1 (v12r2 will have TURN/TCP support). However, browsers with WebRTC support can do TURN/TCP today.
Using the built-in TURN Serverinnovaphone devices can be used as TURN server. This is enabled by defining at least one TURN account with password in
- the local (private) IP address of the phone which is good for conversations to another phone in the same private network
- the external address of the internet router (the address detected by a STUN server) which is good for conversations to peer in the internet
- the address of a TURN server which is good for conversations to peers in foreign private networks
So when an endpoint establishes a call, it has to decide which IP address to expose to the remote peer. Unfortunately, the endpoint usually cannot make this decision rightfully. This is because in order to do a good decision here, the endpoint would need to know the details of the network path to the remote peer. However, this is usually not known to the endpoint.
This issue is addressed by Interactive Call Establishment, or ICE. The idea behind ICE is that instead of publishing the IP address, the endpoint would note a whole set of addresses which may or may not be useful for media transmission. These addresses are known as candidates. The peer would therefore receive a set of possible candidates and would in turn respond with a set of its own candidates. The endpoints then would exercise all possible combination of these candidates and try to send and receive media data (don't worry, the choices are tried in parallel, so it won't take too long).
Moreover, the candidates are tagged with their type, so that the peers could prefer more desirable candidates. Just think of an internal call between two phones on the same LAN. For sure, using the TURN server would work. But it would be clearly undesirable, as a simple intra-LAN communication (hence using the phones respective private IP addresses) would do.
ICE is used by default, so it does not need to be enabled explicitly. However, for ICE to work, a STUN (or TURN or both) server must be known to all endpoints. To get the benefit of ICE, you need to set a STUN/TURN server in the IP4/General.
The MyPBX-launcher will use the STUN/TURN server configured for the currently selected phone for video and application-sharing media streams. WebRTC media streams will use the STUN server setting configured for the user's registration PBX (that is, those set in IP4/General/STUN or received by DHCP).
This setting can also be deployed using the STUN Server and TURN Server vendor options of the DHCP server (set it to the IP address or DNS name of your STUN/TURN server). For a complete list of supported options see
The full picture
We end up with a scenario, where all techniques (STUN, TURN) are available and the right choice is done with ICE:
The ICE information (candidates) is exchanged between the endpoint using the signalling connections (H.323/H.245 and SIP/SDP) in this case.
Troubleshooting STUN and ICE
When you try a call then, the trace will show you the ICE candidates gathered with STUN:
ICE.0: Connected successfully ...
ICE.0: Conclusion SUCCESS
ICE.0: Connection failed (no working network path found)
ICE.0: Conclusion FAILED
ICE.0: Connection aborted (ICE might have failed at remote endpoint)
ICE.0: Conclusion ABORTED
Please note that not all trace messages marked as Error need to be real final errors. For example, if you see Error 1025 remote party not ready, yet?, this is only a temporary failure during ICE. You should look for the Conclusion message.
This way, the reverse proxy can distribute requests to multiple services while using a single port (port 80 for HTTP in the picture above) only. It functions as a single access point for multiple services in the network.
Unlike with a NAT forward, the incoming requests (as well as the returning responses) are not just passed through (after some address translation). Instead, both ends of the connection (client->RP and RP->server) are separate TCP connections. That is, the RP terminates the connection from the client and creates a new one to the service.
This allows the RP for example to have encrypted traffic on one side and un-encrypted traffic on the other side.
Of course, it is also possible to have it the other way round or to have it symmetrically.
As the RP maintains separate connection both to the client and the end service, a client using a service through the RP will always receive the RP's certificate as server certificate. Currently (v12r1 preview), the RP will always present its own device certificate to the client.
There is some special certificate interaction between the RP and a PBX. See chapter Reverse Proxy and PBX Interaction later in this book for details.
Client IP Addresses
Note though that for the same reason (separate connection), the receiving service will neither know the real IP address of the requester nor will it see the real certificate (if the requester sent one). After all, the RP is a classic man-in-the-middle.
The RP will however send an
The RP is part of the basic firmware and is available on all gateway platforms. No license required.
TCP based services such as HTTP, LDAP, H.225, SIP are connected through a well-known, that is, fixed port. HTTP(S) use TCP port 80/443, LDAP(S) 389/636, H.225 1720/1300 and SIP(S) 5060/5061 by default.
GatekeeperRequest or RegistrationRequest messages are routed based on the gatekeeper ID.
For calls without registration, the called party format user@domain is expected and the call is routed based on the domain part.
By default, H323/TCP uses port 1720, H.323/TLS port 1300
REGISTER and INVITE messages are routed based on the domain part of the URI in the From: header.
By default SIP uses port 5060, SIPS port 5061
All types of HTTP requests are routed based on the HTTP Host: header.
By default, HTTP uses port 80, HTTPS port 443.
BIND requests are routed based on the domain part of the user which must be either in the form domain\user. (e.g. innovaphone.com\ckl) or in the CN=user, DC=domain, DC=top-level-domain form (e.g. CN=ckl, DC=innovaphone, DC=com). In the latter form, all DC= components are concatenated to form the target domain name.
By default, LDAP uses port 389, LDAPS port 636.
The RP does not support Kerberos authentication. If you intend to use Kerberos for authentication on remote devices, you need to configure it like in v10/v11: you need to configure a NAT map on your internet router towards the Kerberos server. However, this will be not necessary in many installations.
All suspicious requests are counted on a per-requester (IP-address) base. As soon as the number of such requests per minute exceeds a certain threshold, the requester is put on a blacklist and any further request is blocked for a certain amount of time.
This provides good protection against e.g. brute force attacks.
Requests are considered suspicious
- if they are either rejected by the RP itself (e.g. bad certificate) or
- if the connection to the service did not succeed
- if they are rejected by the service (e.g. brute-force register attack)
A requester is put into the blacklist when it has sent too many suspicious requests in a single minute. This entry has a time-out though. When the time-out expires, the blacklist entry is removed. This way, a device that has sent suspicious requests due to a wrong configuration will work once the configuration has been fixed and the time-out expires. No administrator intervention required on the RP.
The Suspicious Requests/min threshold can be configured. Also, the Blacklist Expiration(min) time-out
If a requester is known to produce many suspicious requests for good reason, the RP administrator can change the blacklist entry into a whitelist entry. A requester that is in the whitelist will never be blocked by the RP.
Both black- and white-list entries can be created manually.
Reverse Proxy and Routing
However, in some scenarios, the routing equipment is already set and cannot be changed. Still, a RP can be used.
In fact, the RP does not need to work as a router also nor it is necessary to have a DMZ. If there already is a router, the RP can also be placed into the local network with no direct connection to the internet. In this case, the NAT router must provide static NAT maps for all the services the RP shall work with. These must send all traffic for these services to the RP.
Reverse Proxy and Media
If a server for media/RTP relay is needed, the TURN server is to be used.
Reverse Proxy and PBX Interaction
On the PBX, a list of RP IP-addresses (no DNS names allowed) must be configured.
- the RP will validate incoming H.323/TLS registrations against their certificate, if the Check Certificate is set for the target
- If the certificate is valid for the registration (that is, the certificate is trusted as per the RP's trust list and the name (a.k.a. CN) in the certificate matches the registration name), the registration is forwarded to the PBX using TLS
- If the certificate is not valid or the incoming registration was sent with TCP (not TLS) or the Check Certificate check-mark is not set, it is forwarded to the PBX using TCP
- a registration from an RP (as per the defined list of RPs in the PBX/Config/General) is never accepted unless the Reverse Proxy check-mark is set in the user's respective Device entry. This way, the administrator can control which user and which devices may be used from external (via the RP). To control external registrations, it is therefore important to list all RPs here!
- if the Assume TLS check-mark is set in the PBX (next to the list of RPs), an incoming registration with H.323/TLS is assumed to have a valid certificate (although the certificate itself is not valid, as it is the RP's certificate). This will allow registrations on Devices where TLS Only is set
- an incoming registration from an RP with H.323/TCP (no TLS) is treated like a normal registration (that is: the password is checked)
- unlike normal registrations, such registration is never allowed when there is no password in it
For this scheme to work, you obviously need to specify both H.323/TCP and H.323/TLS targets in your service definitions!
SIP REGISTER requests are handled similar to the H.323 scheme explained here.
How to Register Devices with questionable Certificates (e.g. myPBX for Android, myPBX for iOS, Softwarephone)
The scheme outlined above allows registrations of devices which have no real trustable certificate, e.g. self-signed certificates used on soft clients. You would configure the client similar to those with good certificates. However, as the certificate verification will fail in the RP, you would also provide a password (either the user password or - slightly more secure - the PBX password).
Service Type Definition
If no port is configured for a service type, the RP will not forward any request of this type. Note that plain and encrypted service types are configured separately. In the example above, service types H.323/TLS, LDAPS, HTTP and HTTPS are forwarded whereas H.323/TCP, SIP/TCP, SIP/TLS and LDAP are not.
Service Name Definition
In the example shown, a service name innovaphone.com is defined.
- Unencrypted H.323 requests for this name are forwarded to 172.16.0.10 port 1720, encrypted request to port 1300
- Unencrypted and encrypted LDAP requests are forwarded to 172.16.0.90 port 636
- all other requests (SIP and HTTP) are not forwarded
If for a protocol type both encrypted and unencrypted target ports are specified, the RP will forward requests with no change in encryption type (that is, encrypted requests will be forwarded encrypted and unencrypted requests will be forwarded unencrypted).
If only one target port is defined, requests in both encryption types will be forwarded with the encryption type a target port is defined for (that is, if only a TLS target port is specified, both encrypted and unencrypted requests are forwarded as encrypted requests).
Keep in mind that the type of requests that are accepted in the first place depends on the settings in the service type definition. In our example, although unencrypted LDAP requests could be forwarded encrypted, they are not allowed anyway as there is no entry for LDAP in the service type definition (there is only one for LDAPS).
See Supported Services above for the interpretation of the defined service Name.
Access to such named services can be restricted by specifying a list of allowed IP-address/network-masks per request type.
For HTTP/HTTPS requests, the allowed URLs can be specified but keep in mind that URLs are case sensitive.
The allowed URLs are evaluated against a requested URL as follows:
- one of the defined URL must match the initial part of the requested URL (head match)
- if the matching defined URL ends with a slash (/), the remainder of the requested URL (the unmatched part) must not contain a slash
Using the Gatekeeper ID in H.323 Register Requests
To route requests from a phone configured with a gatekeeper ID innovaphone.com, you would create a service name definition for innovaphone.com. The RP would forward the registration to the defined PBX (172.16.0.10 in our example).
Let us assume this PBX is a master PBX and the user has to be registered in a slave PBX. The master would then reject the registration and the rejection would be accompanied by a hint that redirects the phone to the right slave PBX (you learn more on this in theDistributed PBX book).
When the second registration requests arrives from the phone, the RP needs to do the right routing decision. Obviously, since the RP does its routing decision for H.323 requests based on the gatekeeper ID only, the new information needs to be coded into the gatekeeper ID.
This is done using the following syntax:
(both location and registration-location are optional).
The physical-location is ignored by the RP for routing decisions. The registration-location is ignored by the PBX during registration.
The second registration from the phone will thus have a /branch suffix in the gatekeeper ID (innovaphone.com/branch). In fact, it will also have a hq@ prefix to pass the client's physical location to the slave PBX (firstname.lastname@example.org/branch), but this has no effect on the RP's routing decision.
To do the right forwarding decision, the RP needs a separate service name definition for each slave PBX (innovaphone.com/branch in our example).
Using the registration-location explicitly
You can also use the /registration-location syntax explicitly in a registration setup. If so, the RP will forward the registration to the slave PBX right away. This is useful if you care for the registered client's physical location (for example when non-local trunk lines are used in slaves).
Gatekeeper-ID and Standby PBX
As we have seen, the reverse proxy routes registration requests based on the gatekeeper ID (possibly taking into account a location indication). However, this scheme does not allow addressing of a standby PBX (as this will share the same gatekeeper ID and location with the PBX it stands-in for).
To fix this, endpoints can be configured with a special syntax for the registration-location in the gatekeeper id:
The phone would use the primary-registration-location when the registration is sent to the Primary Gatekeeper, the secondary-registration-location when it is sent to the Secondary Gatekeeper. For example, if the gatekeeper ID is configured as innovaphone.com/hq:hq-standby, you could have one service like innovaphone.com/hq for the master PBX and innovaphone.com/hq-standby for the standby PBX in the reverse proxy.
Reverse Proxy and DNS
To address this issue, you could carefully configure each requester correctly either with the RP's address (for external requesters) or the local address of the service (for internal requesters). However, this is cumbersome and fails completely for moving devices such as e.g. smart phones with a myPBX client on it. The administrator or end user would always need to re-configure such devices whenever they are moved. Clearly undesirable.
Using local/global DNS for Service Addresses
The solution is to use DNS names for all services (instead of plain IP addresses) in combination with internal and external DNS services.
The idea is to use to have one global DNS service that maps all service host names to the public address of the RP that can forward requests to them. In addition, you have one local DNS per site (where site here refers to a single routable network). The local DNS servers would map only local services to their local addresses. Any name resolution request for non-local services would be relayed to the global DNS.
As requesters usually receive their DNS settings with DHCP, moving clients would automatically reconfigure themselves to use the appropriate DNS.
As a practical example, you would use a DNS name instead of an IP address for the Call List Service in the PBX myPBX configuration.
DNS Names for PBXs
DNS names assigned to PBXs must be made known to the PBX in the PBX/General configuration. This is because the PBX's DNS name must be passed back to a registering client during the redirection process (see previous chapter).
How to run a local DNS
Many companies already run their own local DNS. However, if you do not, you can run a simple DNS on any innovaphone gateway platform.
Your global DNS however must be properly registered with the global domain name system, otherwise moving requesters in the internet would not be able to find it. This is why you need to use the DNS your internet provider offers you in many cases (of course, you can run one yourself too).
It is not recommended to use the innovaphone built-in DNS service as global DNS!
Reverse Proxy and LDAP Replication
- slave replication in PBX/Config/General
- explicit replication in LDAP/Services/Replicator
The explicit replication is easily configured to work through the reverse proxy. You simply need to make sure the LDAP user used has the domain\user syntax.
For the slave replication however, you do not (and can not) configure an LDAP user name (this name is derived implicitly by both the master and the slave PBX). At the time of this writing (before v12r1 release), the user name implicitly used for this is not in the right format. You need to turn slave replication off and use the explicit replication. However, this shall be fixed and the slave replication shall use an LDAP name like gatekeeper-id\derived-user-name. So this will work out-of-the-box.
Reverse Proxy and Certificates
As an example, let us recall the asymmetric HTTP access scenario where the RP receives encrypted requests and forwards them un-encrypted. In this case, the client's browser will see (and verify) the RP's certificate only. Even if the forwarded requests would be encrypted, while the RP sees the service's own certificate, the client would still see only the RP's certificate.
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.
Browser Certificate Verification
Modern browsers will warn you (Firefox example) if you connect to a web site with HTTPS and this site presents an untrusted certificate (if the web site is an . There can be several reasons for this, the main reasons are:
- the certificate is issued by an unknown CA (certificate authority)
The fix for this is - if you intend to trust this CA but your browser doesn't know it - to import the certificate issuers certificate in to the list of trusted CAs
- the certificate is not issued for the service that is being accessed
In this case, the names listed in the service do not match the name you used to access the service (e.g. you have used the URL https://hq.innovaphone.com and the certificate does not list hq.innovaphone.com as valid name). The fix for this is to use a certificate with a proper name
Changing a Device Certificate
An innovaphone device will present its own device certificate (as set in the Device certificate section in
So 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----
Creating a new Device Certificate
To create a new certificate for your device, you can create a signing request on this device in
Please keep in mind that the device certificate's key length greatly influences TLS performance (see
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 (Egde, 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.
Reverse Proxy and SIP Providers
- never vice versa (we ignore the rare conditions where a SIP provider is used in non-registered fashion)!
SIP Trunk security is not provided by the RP, but by the SBC function that is part of the SIP interfaces.
Note though: while the RP is not involved in SIP trunk access, the RP and the SBC (SIP-IF) can (and will in many scenarios) run on the same box!
Reverse Proxy and Zero Configuration Deployment
When such endpoints registrations are done via a reverse proxy, you need to tick the With PBX Pwd only checkmark. In this case, if the endpoints presents a trusted certificate along with its registration, the deployment will be done and the TLS only check-mark will be ticked in the respective Devices entry of the PBX User object. The admin must then confirm access from remote by checking the Reverse Proxy check-mark too.
Internet Access Scenarios
Let's discuss some typical scenarios.
The idea with a DMZ is that no traffic can be routed directly from the internet to the company LAN. Instead, all traffic is relayed only by a trusted entity in the DMZ in a (hopefully) controlled fashion.
You implement this by installing an innovaphone gateway platform (an IPVA or IP0011 would suit well) in the DMZ. Incoming H.323, SIP, LDAP and HTTP traffic is relayed by the reverse proxy. Traffic to a SIP provider is handled by the SBC (SIP-IFs) and RTP is handled by the TURN server (or for traffic from/to the SIP trunk the SBC when media-relay is enabled for the SIP-IF).
Also please note that the scenario shown here - although it is quite common and also useful - is in fact rather strange. The fundamental idea of TURN (as discussed in the TURN chapter above) is to make sure that arbitrary clients can establish media streams between each other. Both users would typically use their own TURN server (if required). The TURN servers would be spread over he internet so as to optimize media-traffic routing. Therefore, the vanilla scenario would look more like this one:
However, very often, IT organizations have a hard time to install and run services "somewhere" in the internet. Also, in many cases, the clients will be users within the same organization and will use the same TURN server anyway.
Reverse Proxy on Router
Please note that for the PBX and its related services, no NAT is required in this scenario as all traffic is relayed by the innovaphone box! However, in real life, you would still need to enable NAT on the box, as the customer will certainly want to use other services (such as e.g. outgoing web access) that require NAT.
You would use the external address of the reverse proxy box as TURN server address so that the TURN endpoints have an address that is reachable both for internal and external clients. However, in fact the TURN server is not necessary at all in this scenario as an innovaphone box will always do full-cone NAT, so RTP will work without TURN anyway!
This scenario is possible. However, please note that it is not required to use our box as router to run a working scenario. We therefore only recommend this, if you decide for other reasons to use an innovaphone box as router.
Reverse Proxy internally
In this case, you would use a slightly different approach: you install an innovaphone gateway platform in the customer's LAN.
The difference here is that the NAT router must be configured with some static NAT maps which route incoming H.323, HTTP, LDAP, TURN (and - only if required - SIP) traffic to the innovaphone box. This is not a security issue, as all such traffic would be sent only to the innovaphone box that is running the reverse proxy and TURN server. This makes sure that no attack based on these services is possible towards other devices (e.g. the PBX).
Again, there is no need to use 2 Ethernet interfaces on the reverse proxy box. In fact we do recommend to use a single IP address and interface only.
In this scenario, the TURN endpoints created and offered by the TURN server will all have internal IP addresses. For this reason, the scenario will work only if all clients are using the same TURN server!
Note that a NAT map for SIP is not required for outgoing SIP requests (that is: not for using SIP trunks).
Note also, that while you can install both the reverse proxy and the TURN server in your local network, you cannot meaningfully install the STUN server within your local network. This is because the STUN server must be located behind the NAT router (as seen from the phone) to work properly (see the STUN chapter above for why this is the case).
Reverse Proxy internally with PBX
To make this work, you would need to create static NAT maps for the standard service ports in the NAT router but send the traffic to non-standard ports on the reverse proxy. The RP itself would forward the request to itself, but on the standard port again.
While this may look appealing as you save a device (and the invest), we do not recommend to do it.
The reason is two folded:
- the configuration is somehow non-intuitive and error-prone. This is because you would need to run services twice: one time the real service (e.g. the PBX) and one time the reverse proxy
- this opens your PBX for all kinds of attacks. Although such malicious request would still be controlled (and probably rejected) by the RP, it will cause network and CPU load on your PBX and may thus result in service quality loss and e.g. nobody in the customer company could use his phone and e.g. make an (emergency) call.
Attaching the PBX directly to the internet is dangerous and thus not recommended.
Please note that this does not apply to outbound requests only like used for SIP trunks. You can safely run a PBX with SBC (SIP-IFs) on it to use SIP trunk services (provided your SIP trunk uses registration mode).
Putting it all together
Let us first have a look at which PBX services we are actually talking of
- An endpoint (e.g. phone) will want to register with the PBX and place calls. So H.323 call signalling has to work
- During a call, media (voice, video, application sharing) needs to be exchanged. So (S)RTP has to work
- The endpoint will want to search phone books for name look-up and reverse calling number resolution. So LDAP(S) directory access to the PBX and/or a separate directory service has to work
- The remote user may have a myPBX client running which requires HTTP(S) access to the PBX (and possibly the reporting service if it provides the call lists)
When it comes to public access, we have to consider the routing schemes used in the network.
The complete Workload Picture
The above pictures are a bit simplified of course
So please find a more complete picture here innovaphone Workload.
TCP based Services
To make such services work, the reverse proxy is used as discussed before.
Reverse Proxy and the Administration web UI
You will configure the RP to forward HTTP/HTTPS in virtually all scenarios. Keep in mind that doing so will create a potentially dangerous situation: as the RP will take all incoming HTTP/HTTPS connections then, you will have a hard time to reach the admin web interface any further.
So make it a habit to change the HTTP/HTTPS ports for the box you run the reverse proxy on to a non-standard port (or more precisely, to a port that the RP is not handling).
Reverse Proxy and LDAP
You will configure the RP to forward LDAP/LDAPS in virtually all scenarios. If you use the default Ports 389 and 636, the internal LDAP Service should be disabled before.
UDP based Protocols
Looking at our protocol drawing again, we see that UDP is used by RTP and RAS. RTP traffic is handled by STUN/TURN/ICE as outlined above.
The solution for RAS is to get rid of it altogether
RAS and H.460.17
However, neither H.323/TLS nor H.323/TCP is used by default. The default is using UDP based RAS (known as protocol type H.323). To get the benefit of tunnelled RAS, you need to set H.323/TLS in the Protocol property of an endpoint.
This setting can also be deployed using the VoIP Protocol vendor option of the DHCP server (set it to H.323/TCP or H.323/TLS). For a complete list of supported options see
H.323/TLS for Slave PBXs
Slave PBXs do register with their respective master using H.323. By default, UDP-based H.323 is used. If access to the master is provided through a reverse proxy, H.323/TCP or H.323/TLS must be used. This can be configured in the PBX/General configuration.
Choosing Service and DNS Names
To choose the right service name(s) here is simple - you have no choice The service name must match the PBX gatekeeper id, which is the value of the System Name property in
However, as we have seen before, one service name is not enough if you have some slaves in the scenario. Each slave needs a separate service name consisting of the gatekeeper ID with the value of the slave's PBX Name attribute appended, e.g. innovaphone.com/branch-a.
For orthogonality, you may want to create an additional service name for the master pbx like innovaphone.com/hq. (assuming the master hq as PBX Name). However, it is not strictly required, as any slave that redirects to the master will use the plain gatekeeper ID syntax (innovaphone.com) to do so.
You should have one DNS name for each of the PBXs. However, due to the naming rules for DNS names, they can't be identical to the service names. Instead you would prefix the System Name with the PBX Name. In our example, you would end up with hq.innovaphone.com and branch-a.innovaphone.com as DNS names. Please note that you normally can not use a bare innovaphone.com as DNS name for the master, cause this name is usually used otherwise already (e.g. as an alias for the company's web server)
innovaphone PBX clients (phones, remote PBXs, ...) usually do not use SIP. So thee is no need to configure service names for SIP. Note that of course SIP trunks may be connected to the PBX. However, such connections are outbound (as seen from the PBX) and do not touch the RP at all.
3rd party SIP devices are not recommended to use in a public-access setup. Very often these devices don't support the required NAT-traversal mechanism like ICE, TURN, STUN. This will result in audio problems, as described in the beginning of this book.
myPBX needs a HTTP connection to the PBX to function. Depending on the registration PBX that is configured for the user, the connection is established to the appropriate slave PBX.
To make this available for HTTP, you should use sub-domain-style service names (hq.innovaphone.com and branch-a.innovaphone.com). As a result, you can use the same DNS names as for H.323.
The URLs to allow are
- /PBX0/MY (myPBX client)
- /PBX0/WEBSOCKET (myPBX client)
- /PBX0/DEVICES (video/collaboration channel registration (launcher))
- /CDR0/CALL-LIST (credentials for call list access)
- /apps/innovaphone-reporting/mypbx (if Reporting is used for call lists, see next Chapter)
From v12r2, if you want to run PBX-Apps, you need to allow in addition
For myPBX, you will also need to provide HTTP access to your call reporting service. This could be the PBX itself or it could be a separate reporting service on a Linux Application Platform. In the first case, you would again use the sub-domain-style service names (hq.innovaphone.com and branch-a.innovaphone.com). If a separate reporting service is used, you would need a distinct DNS- and hence service name, e.g. reporting.innovaphone.com.
The URL to allow when you use reporting (on a Linux Application Platform) for call lists is
- /apps/innovaphone-reporting/mypbx (call list info for myPBX)
- /CDR0/CALL-LIST (call list info for myPBX)
If you want to provide general access to the reporting application on the Linux Application Platform (e.g. for report generation), the URLs to allow are
- /apps/innovaphone-reporting (reporting application on LAP)
If you want to allow external PBXs to post CDRs to the reporting service, you must allow the URL
This is a rare case however.
TAPI and SOAP
If you want to allow external PCs to establish TAPI or SOAP connections to the PBX, you must allow the URL
If you want to allow external Operator PCs to control the Nightswitch Boolean, you must add the following URL to the already configured URL's
PHP Update Server
If you want to allow PHP Update Server V2 (without MTLS) via the Reverse Proxy you should NOT change the port from 443 to 80 otherwise the commands will not be forwarded with HTTPS but with HTTP instead.
Because the Rerverse Proxy will only allow port 443, the PHP update commands would be ignored.
When using MTLS you cannot use the Reverse Proxy because the connection from the client must go directly to the server. They must be able to exchange their own certificates.
In case you use a Reverse Proxy the certificate will be exchanged with the RP and therefore not directly from client to the server, causing the authentication to fail.
In most installations, you will use 2 LDAP services: the PBX itself (for information about PBX extensions) and some sort of corporate directory service (such as e.g. MetaDirectory).
For the PBX LDAP access, you can again use the sub-domain-style service names (hq.innovaphone.com and branch-a.innovaphone.com). This however requires an LDAP user in the domain\user style to exist in the Accounts list of the PBX LDAP server in
Please note that the default configuration of an innovaphone phone uses uses ldap-guest as LDAP client user. This of course will not work through the proxy, as there is no domain part in this name. So you need to change this configuration (e.g. by using config templates).
If you use a 3rd party LDAP server, you will need to create a similar account in this server.
In the end, the RP configuration may look similar to this one:
Reverse Proxy and Firewalls
You need thus to make sure that the firewall lets all requests pass from the requesting devices to the reverse proxy. Also, it must not tamper with the requests (i.e. a man-in-the-middle like proxy type of operation will stop the RP from working properly).
Here are some guidelines. Make sure that the firewall
- allows all the protocols shown in the innovaphone Workload to pass
- allows TLS connections with a TLS version supported by the firmware used (up to 12r2 this is TLS 1.1, from 13r1 this will be TLS 1.2. See
Security works with innovaphonefor up-to-date details)
- allows TLS connections using the certificates used in the respective devices
- works in a routed/filtered fashion, not in a proxy fashion. If the firewall works as a proxy (i.e. terminate the TLS connection and establish a new one to the destination), the TLS-connections to the RP will use the certificate of the firewall. As a result, the certificate check at the RP will fail.
Here are some options to deal with that load.
Use non-TLS internally
In many cases, there is no need to use encrypted traffic internally (that is, between the reverse proxy and the real service). It is possible to accept encrypted traffic from extern (by specifying the TLS service port in the General Parameters
However, keep in mind that this may not be possible for H.323 / SIP (see Reverse Proxy and PBX Interaction above).
Use IPVA rather than Hardware Gateway
The IPVA (more precisely, the underlying CPU) uses special encryption instructions and has thus substantially better encryption/decryption performance.
Use multiple Reverse Proxy
You can deploy multiple reverse proxy instances and distribute your clients among the instances, e.g. by using different DNS names.