Reference12r1:Concept Reverse Proxy

From innovaphone wiki
Jump to navigation Jump to search

The Reverse Proxy is a software module, which is available on innovaphone gateways. It is designed to allow safe access to services of the innovaphone PBX from the public internet. To accomplish this the gateway must be accessible from the public internet either by NAT port forwarding, or directly. The reverse proxy forwards traffic to configurable destinations. The access to internal destinations can be limited in several ways and algorithms to detect attacks are implemented, which are used to put ip addresses into a blacklist. The reverse proxy supports H.323, SIP, HTTP and LDAP over TCP or TLS.


The reverse proxy only accepts any connections on the supported protocols, if the port numbers for these protocols are configured. The well-known port numbers or non standard port numbers can be used for these protocols.

A timeout may be configured until which an entry in the blacklist is removed automatically.

A threshold suspicious requests per minute can be used to tune detection of attacks.

Forwarding to internal destinations is based on the addressed host. For this the received requests are analyzed and for each supported protocol different elements are used to identify the addressed host.

Basic Operation

Connections are accepted on the configured port. The received protocol is analyzed to determine the addressed host and a internal connection is established to this host. If the incoming connection is TCP for the internal connection TCP is used as well, if the external connection is TLS, for the internal connection TLS is used. If only TCP or only TLS is configured for the internal connection it is used regardless if the incoming connection was TCP or TLS.

If the Check Certificate checkmark is set, for the internal connection TLS is used only if the received certificate matches the user name within the protocol. This way a host receiving a request through the Reverse Proxy using TLS can assume that the connection was authenticated using a valid certificate, which matches the user.

Access to a configured protocol may be limited to certain networks. This is done by configuring a list of networks in a addr:mask form.


For H.323 registrations, the gatekeeper identifier received in GatekeeperRequest or RegistrationRequest messages is matched to the Name configured for the host. Only H.323 over H.225 (H.450-17) is supported.

For calls without registration a destination in the for <user>@<domain> is expected. <domain> is matched to the Name configured for the host. This can be used for H.323 open federation.


For SIP registration the domain part of the FROM header of a REGISTER message is matched to the Name of the configured host.

Also SIP INVITE messages are forwarded by the Reverse Proxy, if the FROM URI matches with the configured host.


For HTTP requests the host header is matched to the Name of the configured host. If within a single TCP/TLS connection requests are sent to different hosts, the outgoing connections are terminated and for the request to the other host a new connection is established.

The path which may be accessed can be restricted, by configuring the allowed path. If the pass is configured with a trailing '/' no access to folders inside this path is allowed.


For LDAP the LDAP_BIND message is analysed. A user in the form <domain>\<user> is expected and the <domain> is matched to the domain part of the name of the configured host.

Attack detection

Attacks are detected based on the frequency of unsuccessful requests. If more then a configured number of such requests are received within a sliding window of 1min the originating IP address is put into the black list.

To provide some indication about current suspicious requests a list with the the 10 remote IP addresses with the highest number of requests is displayed.


A blacklist/whitelist mechanism is used to block IP addresses or grant access to IP addresses regardless of attack detection. An entry into list can be configured with a timeout, so that it will be removed after the timeout automatically. Entries generated by the attack detection use the configured timeout.

A blacklist entry can be easily changed to a whitelist entry by setting the whitelist checkmark.

Reverse Proxy with innovaphone PBX

The innovaphone PBX has some features implemented especially for integration with the Reverse Proxy.

Controlling Authentication

On the innovaphone PBX up to 8 Reverse Proxies can be configured which are used to forward requests to the PBX. A Reverse Proxy is identified by its IP address. Optionally a certificate name can be configured for a Reverse Proxy, to verify that the connection really sent by the Reverse Proxy and not just relayed by some other equipment.

Registrations through a Reverse Proxy are only accepted if the Reverse Proxy flag at the destination device is set. This way no unexpected registration is possible. When the Assume TLS checkmark is set, a registration received from the Reverse Proxy via TLS is assumed to be authenticated with a proper TLS certificate on the Reverse Proxy already. So no further authentication is required on the PBX. Such a registration is accepted also if TLS Only is set on the device. If a registration from the Reverse Proxy is received via TCP password authentication is required.

Support for multiple Slave PBXs

To address a specific Slave PBX through a Reverse Proxy, a GK-ID with the format <domain>/<location> can be used. A PBX ignores anything in the GK-ID after the '/'. This way in the Reverse Proxy for each slave PBX sharing all the same domain a separate host entry can be configured.

On the phone this format can be used to address the correct destination PBX.

If the registration redirect mechanism shall be used, so that all client can share the same configuration, normally the PBX redirects to the IP address of the correct slave. In this case this does not work since from the public internet the internal addresses are inaccessible, so DNS Names must be configured on all PBXs. In the external DNS these DNS names must all be resolved to the Remote Proxy. The PBX changes the redirect GK-ID to contain the new location in the above format.

The physical location of the phone in case of redirection is the PBX to which the first registration was made. The PBX uses the <physical-location>@domain... format of the GK-ID on redirection.

Physical location and registration PBX can be configured manually on the phone by using a GK-ID of <physical-location>@domain/<registration PBX>

Support for Standby PBXs

To address different PBXs for the primary and the alternate registration different GK-IDs have to be used for the primary and alternate (standby) PBX in the form of <domain>/<location> with a different location for primary and alternate. This way in the reverse proxy different host entries can be configured to address the active and standby PBX. To configure this on innovaphone endpoints a GK-ID in the form <domain>/<primary>:<alternate> can be configured. For the primary registration <domain>/<primary> and for the alternate registration <domain>/<alternate> is then used.

Configuration Items used

Command line arguments

The reverse proxy uses the following command line arguments (the arguments found on the "config change REVERSE-PROXY" line:

/h323 <port>
The H.323/TCP listening port
/sip <port>
The SIP/TCP listening port
/ldap <port>
The LDAP listening port
/http <port>
The HTTP listening port
/h323s <port>
The H.323/TLS listening port
/sips <port>
The SIP/TLS listening port
/ldaps <port>
The LDAPS listening port
/https <port>
The HTTPS listening port
/expire <mins>
The blacklist expiration timeout in minutes
/threshold <num>
Number of suspicous requests per minute, which causes a blacklist entry
/public-nat-addr <ip-address>
The public address of the NAT router, which forwards the requests to the RP. Needed for SIP, so that the correct address for further requests can be provided
Log rejected HTTP requests
Log forwarded HTTP requests
Log rejected LDAP requests
Log forwarded LDAP requests
Log rejected SIP requests
Log forwarded SIP requests
Log rejected H.323 requests
Log forwarded H.323 requests

VARS used for Host definitions

The name of the VARS for host definitions is formed as follows:

RPRXY/H<FNV-1a Hash of Hostname>/<sequence>

FNV-1a Hash of Hostname
The hash is calculated as defined in FNV-1a Hash (32-bit)
If multiple host names yield the same hash value, different sequence numbers are used to create uniqque names

The vars create lines in the config file create these vars. Example:

vars create RPRXY/HD93FC082/00000 ...

The flags used for these VARS are pb (permanent, binary)

The content of the VARS is binary, optimized for quick access to the relevant data.

The general format is

 struct {
     word - offset H.323 mappings
     word - offset SIP mappings
     word - offset LDAP mappings
     word - offset HTTP mappings
     char [] - Hostname, variable length
     byte [] - Mappings
The offsets are a byte offset into the var content to where the mappings info is stored
A variable length zero terminated hostname
Start of the mappings. All mappings are on 4 bytes aligned offsets

For the mappings the following structure is used:

struct {
    IPaddr addr;
    word port;
    word ports;
    word nets;
    word flags;
    word next;
    word ext1;
    word ext2;
    word ext3;
    char path[];
The destination IP address, as IPv6 address. If the destination is IPv4 the mapped IPv4 format is used (::ffff:<IPv4>)
The port used for TCP
The port used for TLS
Offset from the beginning of the mapping to a network filter list, if present. If no filter is defined 0 is set
Flags defined for the mapping. The following values are used:
If set, the certificates of incoming TLS connections are checked
App Login
Default path for a given host
A zero terminated path
ext1, ext2, ext3
Fields reserved for extensions. With these fields, the mapping header is an even 32 bytes
is the offset in bytes from the beginning of this map to the beginning of the next one. It must be 0 for the last map for a host

If nets is set the following structure is used at the indicated offset:

 struct {
     word count;
     word spare;
     struct {
         IPaddr addr;
         IPaddr mask;
     } net;
Number of networks in the list
Used for 4 bytes alignment
Array of addr/mask pairs for the networks, as IPv6 addresses.

VARS used for White/Black list entries

RPRXY/I<FNV-1a Hash of address>/<sequence>

FNV-1a Hash of the address
The hash is calculated as defined in FNV-1a Hash (32-bit)
If multiple addresses yield the same hash value, different sequence numbers are used to create uniqque names

The vars create lines in the config file create these vars. Example:

vars create RPRXY/IC2D83483/00000 ...

The flags used for these VARS are pb (permanent, binary)

The content of the VARS is binary, optimized for quick access to the relevant data.

The following structure is used for the content:

struct {
    dword addr[4];
    byte white;
    byte fill[3];
    time_t date;
    word description_len;
    char description[128];
The address on the list
True if white list entry
For alignment
Unix timestamp of entry into list
Length of description
Description text without terminating zero. A maximum length of 128 characters is stored.

Known Problems

Known Problems