Course13:IT Advanced 2 - 06 Public Access to PBX Resources (theory) - optional

From innovaphone-wiki

Jump to: navigation, search

This book explains how to provide public access to PBX

Contents

Challenges

When it comes to public access to PBX services, there are two major challenges
  • 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

Signalling data (such as SIP or H.323) is communicated between endpoints (i.e. phones) and signalling servers (PBX, Softswitch, SIP provider ...). Often, there are multiple signalling "hops" between the communicating endpoints.

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.




Why that?

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.

NAT

Let us look a little closer on what is happening when a user in a private network accesses the internet. Let us assume a user is surfing in the web. Why does this work if the phone call in our example does not?





NAT


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.

NAT Detection

Most SIP Providers use the same trick to make RTP work.




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). From this point on, the gateway ignores the endpoint's IP address which has been sent to it before as part of the SIP call setup process.

Private to Private Communication



Unfortunately, this only works if one end of the conversation (the provider's PSTN gateway in our previous example) 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. But there is no intermediate gateway that could do the NAT detection trick, so 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.

Media Relay

Some SIP Providers fix that issue by providing so-called media-relay. They simply employ sort of a pseudo-gateway that does nothing but forwarding RTP packets from one client to another.




While this fixes it for on-net calls (that is, for public calls between subscribers connected to the same provider), it does not help for calls between two nodes of the same PBX system. Imagine two users located in two different branch offices of your company want to place a call.





STUN

Looking at the failing scenario it becomes clear that it would work, if both phones would send the public IP address of their respective internet routers to their peer (instead of their own private IP address).




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. This is only done by the router, when a local packet is sent to remote destination. When an RTP packet would be received by an internet router without a corresponding packet sent out before, this router wouldn't know where to forward it.

So, another approach to fix it is 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 for the initial STUN request 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 RTP 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.


Conclusion

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. So STUN may or may not work, depending on the router involved.


STUN in innovaphone devices

Here are some specifics of how STUN is used and configured in Innovaphone devices.

Specifying a STUN server

You can specify a STUN server using one of the following notations:
  • ip-address[:port] (e.g. 151.80.245.247)
    the STUN requests will be sent to the server at ip-address. If the optional :port part is omitted, the STUN standard (3478) is used
  • DNS-name[:port] (e.g. stun.innovaphone.com)
    The DNS will first be queried for an SRV record with name _stun._udp.DNS-name. If this is found, the first SRV record returned will be used. Note that in this case the optional :port part is ignored and the port specified in the SRV record will be used instead.
    Also, the DNS will be queried for an A record with name DNS-name. If this is found, the first A record returned will be used. If the optional :port part is omitted, the STUN standard (3478) is used

Redundant STUN Servers


It is possible to configure two redundant STUN servers. The idea here is that these servers are equivalent, that is, they will return the same external address for calling clients. Both servers will be tried in parallel and when the first one returns an answer it will be used.

This only works when using the ip-address[:port] notation and both servers must be separated by a comma (e.g. 172.16.13.1:1234,172.16.13.2). DNS names for redundant STUN servers are not supported.

Multiple NATed Networks


In rare cases, an endpoint may need to communicate with its peers 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 screenshot.png 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 different logical STUN servers (see fish-help.png IP4/General/STUN), separated by semicolon. You would end up with something like stun.company.com;stun.provider.net.

Note that this is not for redundancy (for this, see Redundant 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. 172.16.13.1:1234,172.16.13.2;stun.provider.net).

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 fish-help.png IP4/NAT/General by ticking the STUN/TURN server / Enable check-mark.

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.

TURN

To work around the possible STUN issue (see the Conclusion in chapter STUN above), a new type of service known as TURN has been developed.

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 screenshot.png 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 screenshot.png need 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 discussed earlier). 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

We have seen that a TURN server "lends" RTP ports to their clients. 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 client device using TURN is irrelevant. The RTP port is of course allocated by the TURN server itself and hence the setting on this TURN server is relevant.

For example, although the myApps launcher would use ports in the range 50100 - 50199 for video RTP locally, its TURN server might offer ports in the 16384+ range.

Internal TURN Server



You may now ask yourself how could I provide TURN services? I don't have the possibility to run a server with an official IP address, so 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 screenshot.png 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 screenshot.png provide enough UDP-NAT ports also.

(Further Hints) TURN works with UDP and TCP by design- You should always support both in your setup (as far as firewall and port-forwarding settings are concerned for example)

Using the built-in TURN Server

innovaphone devices can be used as TURN server. This is enabled by ticking screenshot.png STUN/TURN server / Enable in fish-help.png IP4/NAT/General.

TURN server port

By default, a TURN server uses port 3478, both UDP and TCP are possible.

ICE

One of the drawbacks of all existing VoIP protocols is that endpoints attempt to tell their peer which IP address they have. As we have seen before, the idea of the IP address doesn't work well. In the scenarios we discussed so far, we have seen
  • the local (probably private) IP address of the phone (known as HOST address) which is good for conversations to another phone in the same private network. Such addresses are determined by enumerating the local interfaces
  • the external address of the internet router (the address detected by a STUN server, known as server reflexive (SRFLX) address) which is good for conversations to peers in the internet (with a public IP address). Such address is determined using the STUN protocol
  • the address of a TURN server (known as RELAY address) which is good for conversations to peers in foreign private networks (between devices with private IP addresses from different private networks). Such address is determined using the TURN protocol

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 screenshot.png 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 screenshot.png IP4/General.

The myApps-launcher will use the STUN/TURN server configured in the PBX they are registered with for video and application-sharing media streams (that is, those set in IP4/General/STUN or received by DHCP).

innovaphone devices such as phones and gateways will use their own IP4/General/STUN configuration. Note that the Devices App will apply the same settings for all devices of a single domain using the Media type Device configuration (more precisely: the Install configures the Devices App so that it works like that by default).

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 ICE

Let us assume a scenario with a headquarter HQ, a branch office Branch. There are phones in both locations.


A phone in the headquarter (Phone A) calls another phone in this location (Phone B).

Here is the list of ICE candidates determined by a phone, This example has been taken from an ICE trace made on an innovaphone phone. To see such traces, you must screenshot.png tick the H.323 ICE check-mark in Maintenance/Diagnostics/Tracing.

Debug: ICE.0: Candidates
 :HOST addr([172.31.31.4]:16394/16395) prio(2130569471/2130569726)
 :RELAY addr([172.31.31.2]:16398/16399) related([172.31.31.4]:16394/16395) prio(16641279/16641534)
 :SRFLX addr([77.191.53.70]:35537/35538) related([172.31.31.4]:16394/16395) prio(1693083391/1693083646)
 :SRFLX addr([192.168.178.45]:35537/35538) related([172.31.31.4]:16394/16395) prio(1693083903/1693084158)

There is:

  • a single HOST address: 172.31.31.4
    This is the local IP address of the phone (and a phone only has one IP address usually)
  • a RELAY address: 172.31.31.2
    as we can see, this is obviously an address from the same network. This is because the TURN server in this case runs on the local PBX
  • two SRFLX addresses: 77.191.53.70 and 192.168.178.45
    the first is what we would expect: the public IP address of the internet router. The second is the far end address of a second router that provides NAT access to the corporate network
When Phone A calls to Phone B it tries all these addresses for RTP and finally determines that it can communicate directly (that is, between 172.31.31.4 and 172.31.31.5). So we see:

Debug ICE.0: Connected successfully
RTP(172.31.31.4:16394 -> 172.31.31.5:16390, 0 retries)
RTCP(172.31.31.4:0 -> 172.31.31.5:16391, 0 retries)
ICE.0: Conclusion SUCCESS


If no working RTP connection can be established, you will see

ICE.0: Conclusion FAILED

instead.

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.

Checking the candidates in myApps
myApps has a nice tool to help determine which ICE candidates will be used. For this, you need to configure and start the softphone App. You can then video2.png see the result of an ICE negotiation in the settings and verify that it matches your expectations (especially the SRFLX and RELAY candidates cause those depend on your correct configuration).


Summary

ICE will make sure a functional RTP connection is established.

For media data (RTP) to work you need:
  • a STUN server with a public IP address
    In most cases, you can not meaningfully run a STUN server in your own local network. Your Internet-, SIP- or Hosted-PBX-provider should provide one
  • a TURN server
    This server can have a public IP address or a private IP address
  • In the latter case (private IP address), your TURN server is accessed through your internet router. Therefore, you will need a port forwarding for STUN (tcp and udp port 3478 by default, remember that the TURN server uses the STUN protocol) towards your local TURN server. Also in this case, all endpoints must use the same TURN server
  • your firewall needs to allow outgoing STUN (udp port 3478 by default) so that access to your STUN server works
  • in the case of a local TURN server, your firewall needs to allow incoming STUN (udp port 3478 by default)
  • your firewall needs to allow incoming RTP towards UDP ports 16384 - 32767 for phones and gateways (by default, depending on the settings in fish-help.png IP4/General/Settings which are deployed by the Media type device configuration used in the Devices App) as well as UDP ports 50000 - 50199 for myApps
  • your firewall needs to allow outgoing RTP from above mentioned ports

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.




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.

Asymmetrical Connections



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.

Certificates



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 (v13r1), 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 wikipedia.ico X-Forwarded-For header with HTTP requests to identify the original client. Example:

X-Forwarded-For: 12.34.56.78, 23.45.67.89

indicating that a client with address 12.34.56.78 sent a request via a reverse proxy with address 23.45.67.89.

Licensing



The RP is part of the basic firmware and is available on all gateway platforms. No license required.

Supported Services

The RP fish-help.png supports various TCP based services. Note that the UDP based counterparts are not supported (as the RP supports TCP/TLS only).

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.

For incoming connections, the received content is analysed and then forwarded based of certain properties found in this content.

H.323/TCP H.323/TLS


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

SIP/TCP SIP/TLS


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

HTTP HTTPS


All types of HTTP requests are routed based on the HTTP Host: header.

By default, HTTP uses port 80, HTTPS port 443.

LDAP LDAPS


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.


Fraud Detection

As all external service requests are routed through the RP, it can effectively protect the services.

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)

Blacklist/Whitelist Details

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 screenshot.png blacklist-timer can be defined.

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 IP Routing

The device the RP runs on may or may not run also as an IP router. If it runs on a router that performs NAT (and thus isolates one network from access to its resources from the other side), it functions like a "smarter" type of static NAT map. As such, it allows more flexible and controlled and hence more secured access to internal resources from e.g. the internet.




However, in most 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

As mentioned before, the RP will not handle UDP based services. Therefore, it will not handle RTP media channels.

If a server for media/RTP relay is needed, the TURN server is to be used. Nevertheless, the TURN server can be activated in the same innovaphone device the RP runs on.

Reverse Proxy and PBX Interaction

The RP and the PBX have a few special interactions with respect to H.323 registrations.

On the PBX, a screenshot.png 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 screenshot.png 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 screenshot.png 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 screenshot.png 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 screenshot.png 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
If Check certificate is not set in the RP, request forwarding is transparently done (no switch between TLS/TCP depending on the certificate state) for H.323 as it is for other services.

For this scheme to work, you obviously screenshot.png 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.

Service Type Definition

To configure a service in the RP, you need to configure the listening port to be used for the service in the RP configuration.




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

Requests for enabled services are forwarded only to configured service name. For each name, the target host can be defined as well as the target serivce ports.




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 screenshot.png 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 Limitation


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 screenshot.png 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

Local service type conflicts

Looking at the screenshot.png previous service type example you may notice that the RP is configured to listen on the standard ports 80/443 for HTTP/HTTPS. Fair enough, but how could you then access the normal HTTP services running on that box (e.g. the advanced UI or the SOAP interface)? Obviously, we have a conflict here between the box's HTTP server and the RP, both trying to listen on the same ports.

There are several options to deal with that:
  • do not use the conflicting service
    If you do not need to use the conflicting service, then you can simply ignore the conflict as the reverse proxy is started first and therefore will always use the conflicting port. For example, if the box you are running the RP on does not run a PBX, you probably won't need SIP and H.323

  • re-configure the port used by the "native" service
    In our example, the conflict was with HTTP/HTTPS. You can configure the box's HTTP server screenshot.png to use non-standard ports (e.g HTTP/8000 and HTTPS/8001) in fish-help.png Services/HTTP/Server.

    In this case, you may want to provide a rule in the RP that screenshot.png redirects incoming connections on the standard port to the non-standard port.

Using the Gatekeeper ID in H.323 Register Requests

As explained before, H.323 registration requests are routed based on the gatekeeper ID.

To route requests from a screenshot.png phone configured with a gatekeeper ID innovaphone.com, you would screenshot.png 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.




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:

[physical-location@]domain[/registration-location]

(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 (hq@innovaphone.com/branch), but this has no effect on the RP's routing decision.

To do the right forwarding decision, the RP needs a screenshot.png separate service name definition for each slave PBX (innovaphone.com/branch in our example).

Using the registration-location explicitly


You can also screenshot.png 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:

[physical-location@]domain[/primary-registration-location[:secondary-registration-location]]

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

Reverse Proxy services are usually used by requesters (PCs, phones, ...) which are outside of the corporate network (either in remote branches or somewhere in the internet). Similar clients which are located inside the corporate network however do not need to use it. Even though it may work, you usually don't want internal requesters to use the deviation through the RP.

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 myApps 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 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 screenshot.png use a DNS name instead of an IP address to access the myApps client (which is the recommended method anyway).

DNS Names for PBXs


DNS names assigned to PBXs must be screenshot.png 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 screenshot.png 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!

What if you can't run an internal DNS

If you can't run an internal DNS, it still might work. Your internet router then would need to support hair-pinning. See fish-help.png V13 Installation Scenarios for details.

Reverse Proxy and LDAP Replication

There are 2 places where LDAP replication can be configured
  • slave replication in PBX/Config/General
  • explicit replication in LDAP/Services/Replicator

The explicit replication is screenshot.png 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 screenshot.png do not (and can not) configure an LDAP user name (this name is derived implicitly by both the master and the slave PBX).

(Further Hints) The LDAP bind name implicitly used for the PBX replication is gatekeeper-id\_PBX_ (e.g. dvl-ckl2.net\_PBX_).

Also, if fish-help.png General/Kerberos is used, an additional bind name gatekeeper-id\_KPBX_ (e.g. dvl-ckl2.net\_KPBX_) is used.

Reverse Proxy and 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.

As an example, let us recall the screenshot.png 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 screenshot.png 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 screenshot.png 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 fish-help.png General/Certificates). The standard device certificate on an innovaphone device is issued by the innovaphone Device Certification Authority (or innovaphone Device Certification Authority 2 on newer devices). You can add this certificate to your PCs list of trusted CAs, however, in many cases this will not help. This is because the only name that is mentioned in such a certificate will be something like IP800-06-26-99 (that is, a name based on the device's type and serial number). This will most likely not match the name you use to access the device, as even the correct domain name is missing.

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

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 (Egde, 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.

Reverse Proxy and SIP Providers

Access to SIP providers is not done through the reverse proxy. After all, the RP is for managing incoming requests. When a SIP trunk is registered, the PBX registers with the SIP provider server, so we have an outgoing request. Registration to a SIP provider is screenshot.png always initiated by the PBX

- never vice versa (we ignore the rare conditions where a SIP provider is used in non-registered fashion)!

All external calls are made in the context of this registration.

For the NAT router/firewall, the PBX registration to the provider is an outgoing UDP or TCP/TLS connection (depending on the SIP flavour used) and handled like any other outgoing connection (e.g. web site access). This is also true for incoming calls!

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!

Internet Access Scenarios

There are a number of internet access scenario out there in the field and they have some influence on how to set up the reverse proxy and the SBC (SIP-IFs).

Let's discuss some typical scenarios.

DMZ

Two routers (at least one of them performing NAT and potentially also including firewalls) are located in a Demilitarized Zone (DMZ):




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


Please note that in this scenario, the box running the reverse proxy may or may not use 2 Ethernet interfaces. If you run a flat DMZ, you would connect the box using a single interface only of course. In fact, this is the scenario that we recommend, as it is simpler to understand, configure and debug. However, if you run a segmented DMZ with several subnets in it, you may connect ETH0 and ETH1 to distinct subnets in the DMZ. This is possible and supported but - as noted above - we recommend not to do it if possible.



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 screenshot.png use their own TURN server (if required). The TURN servers would be spread over the 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

In many cases however, the customer does not have a DMZ. In this case, you would use a very similar approach: you install an innovaphone gateway platform like before in the DMZ. The difference would be that it also does the NAT Router job.




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 many cases, the internet access infrastructure is already set and cannot be changed. In this case, an existing NAT router will be used.

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

Theoretically, it is also possible to modify the previous scenario such that the PBX runs on the same box.




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
However, if you cannot afford an extra innovaphone box, his is the scenario you need to use.

No-Nos

Just to clarify this:

You must not expose your PBX to the internet directly!




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



Port conflicts

But what if the ports used by the innovaphone PBX are already used by an existing application?

This will most likely be the case for HTTP (80) and/or HTTPS (443). For example, you might have an Exchange server running with Outlook Web Access or you might have your own web server running.

In this case, the existing port forwardings in your internet router or firewall (towards your existing application) would conflict with the required port forwardings towards the reverse proxy.

In this case, see fish-help.png V13 Installation Scenarios for possible solutions.

Putting it all together

To provide external access to PBX services, the first challenge is simply to make it work technically.

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 possibly 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 myApps client running which requires HTTP(S) access to the PBX and the Application Platform

screenshot.png Protocols used

When it comes to public access, we have to consider the routing schemes used in the network.

screenshot.png Protocols used remotely


The complete Workload Picture


The above pictures are a bit simplified of course wink
So please find a more complete picture here screenshot.png innovaphone Workload.

TCP based Services

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.

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 screenshot.png 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.

Disable_LDAP_Server


UDP based Protocols

With UDP based services, things are more difficult. UDP ports are usually dynamically chosen and thus not well-known in advance. A static NAT map cannot be employed thus nor does the reverse proxy help.

Looking at our protocol screenshot.png drawing again, we see that UDP is used by RTP. RTP traffic is handled by STUN/TURN/ICE as outlined above.

So this is already being taken care of and we only need to fix the TCP services which are relayed by the reverse proxy.

RAS and H.460.17

To fix the UDP NAT issues with RAS, fish-help.png H.460.17 is implemented in the innovaphone devices. This standard defines how to tunnel RAS messages through an existing H.225 (thus TCP) connection. This can be done with unencrypted H.225 (known as protocol type H.323/TCP) or encrypted (known as protocol type H.323/TLS) connection. As far as routing is concerned, we get rid of RAS altogether if H.323/TCP or H.323/TLS is used.

(Further Hints) Endpoints which are configured through a Device configuration in the Devices App (that is, all of your devices in a v13 installation wink) always use H.323/TLS.

For all other devices, neither H.323/TLS nor H.323/TCP is used by default. The default is then using UDP based RAS (known as protocol type H.323). To get the benefit of tunnelled RAS, you need to set screenshot.png H.323/TLS in the Protocol property of an endpoint.


H.323/TLS for Slave PBXs

As you already know, slave PBXs can not be configured in the Devices app. Therefore,
slave PBXs do register with their respective master using UDP-based H.323 is used by default. If access to the master is provided through a reverse proxy, H.323/TCP or H.323/TLS must be used. This can be screenshot.png configured in the PBX/General configuration.

Choosing Service and DNS Names

Let us look at the service names that we need to choose to make a PBX scenario accessible through the RP.

H.323


To choose the right service name(s) here is simple - you have no choice wink The service name must match the PBX gatekeeper id, which is the value of the System Name property in fish-help.png PBX/Config/General. In most scenarios, this will be the principal email domain, e.g. innovaphone.com.

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)

SIP


innovaphone PBX clients (phones, remote PBXs, ...) usually do not use SIP. So there 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.

myApps


myApps needs a HTTP(S) connection to the PBX to function. Depending on the registration PBX that is configured for the user, the connection is established to the master PBX or to the appropriate slave PBX.

To make all the PBXs available for HTTP(S), 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 towards any PBX are
  • /PBX0/APPCLIENT/appclient.htm - myApps client
  • /PBX0/APPS - PBX apps
  • /PBX0/session - myApps two-factor authentication

Legacy myPBX


     
To also allow legacy myPBX usage, the following HTTPS(S) URLs must be forwarded
  • /PBX0/MY - myPBX client
  • /PBX0/DEVICES - mypbx codec registrations
  • /PBX0/WEBSOCKET - mypbx und toolbox (widgets) websocket connections
  • /CDR0/CALL-LIST - myPBX call list access if call-list is run on the PBX
  • /PBX0/APPS - PBX apps
  • /PBX0/web/js - JS scripts
  • /fonts - fonts

Apps running on the AP

To provide access to Apps on the AP, you can forward just any HTTP URL to the AP (e.g. to apps.innovaphone.com). This is safe cause there are no other accessible URLs on the AP except for the installed Apps. The Install does so by creating a single entry for HTTP that forwards any URL to the AP.

If you want to limit access to particular App instances, you would create individual entries for each App. The URL to map is the Webserver path of the App instance you want to make accessible. You will find it in the instance settings in the AP manager. For example, to allow access to the Devices App instance as installed by the Install process, use
  • /innovaphone.com/devices - the instance called devices of the Devices App
     
In contrast to the AP, the PBX has more URLs (e.g. the advanced UI) which you probably want to hide through the Reverse Proxy. This is why it is not recommended to simply forward any URL.

TAPI and SOAP


If you want to allow external PCs to establish TAPI or SOAP connections to the PBX, you must allow the URL

  • /PBX0/user.soap

for each PBX (that is, on the master and all slaves).

Operator


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

  • /PBX0/ADMIN
for the master PBX.

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 because otherwise the commands will not be forwarded with HTTPS but with HTTP. Forward HTTPS to 443 and http to 80 instead.


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 certificates will be exchanged between the Reverse Proxy and the update server and therefore not directly between client and the update server, causing the authentication to fail (as the update server sees the wrong certificate).


LDAP

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. the Contacts App).

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 fish-help.png Services/LDAP/Server. You could for example screenshot.png configure the account hq.innovaphone.com\ldap-guest for access to the PBX LDAP. hq.innovaphone.com then would be the Hostname you need to create an entry for in the Reverse Proxy configuration for LDAP.

The Install creates forwards for both the master PBX (e.g. hq.innovaphone.com) and the domain (e.g. innovaphone.com) and forwards both to the master PBX. However, it only creates a user entry for the domain (e.g. innovaphone.com\ldap-guest) in the LDAP server. If a host-based access shall be possible, you would need to add a user like hq.innovaphone.com\ldap-guest to the Services/LDAP configuration on the master PBX.

If you use a 3rd party LDAP server, you will need to create a screenshot.png similar account in this server.

Sample

In the end, the RP configuration may look similar to this one:



Reverse Proxy and Firewalls

One of the most prominent reasons for a non-functional reverse proxy is a mis-configured firewall (either in the network local to the reverse proxy or in the network of the calling device).

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 https://class.innovaphone.com/moodle2/pix/f/image.gif innovaphone Workload to pass
  • allows TLS connections with a TLS version supported by the firmware used (TLS 1.1 and TLS 1.2). See fish-help.png Security works with innovaphone for 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. terminates the TLS connection and establishs 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.

Performance

Generally, the reverse proxy has to look at the packet contents to do its routing decisions. Therefore, all TLS connections are terminated (that is encrypted/decrypted) . This of course creates substantial load.

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 external traffic (by specifying the TLS service port in the General Parameters fish-help.png Services/Reverse-Proxy) and to forward the same requests un-encrypted (by specifying only the non-TLS port in the Service Name Definition). This will save one encrypt/decrypt cycle per request.

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.
Personal tools