Course12:Advanced - Reverse Proxy

From innovaphone wiki
Jump to navigation Jump to search

This book explains how to provide public access to PBX

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




The answer is two folded.

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.

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

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

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.

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


NAT Types


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.

screenshot.png 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 screenshot.png 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 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 logically 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 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. 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 Enable STUN 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 STUN issue, 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 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 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.

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 Server

innovaphone devices can be used as TURN server. This is enabled by screenshot.png defining at least one TURN account with password in fish-help.png IP4/NAT/General (up to 4 accounts can be specified).

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 (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 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 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 screenshot.png IP address or DNS name of your STUN/TURN server). For a complete list of supported options see fish-help.png IP4/ETH/DHCP-Server. If your router is the STUN/TURN server, you need to specify its external address.

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

To troubleshoot STUN and ICE setting, you should screenshot.png tick the H.323 ICE check-mark in Maintenance/Diagnostics/Tracing.

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.

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

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.

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 SIPS


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.

Kerberos


The RP does not support Kerberos authentication. If you intend to use Kerberos for authentication on remote devices, you need to configure it fish-help.png 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.

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 Routing

    The RP may or may not run on a 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 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

    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.

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

    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

      To configure a service in the RP, you need to configure the 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

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

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

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

      Reverse Proxy and Zero Configuration Deployment

      Zero Configuration Deployment is a method to link endpointsd (telephones) to user objects during deployments (described in the PBX - initial Configuration book found in the Basic Training). This method allows endpoints to register with the PBX using the PBX password or even without any credentials.

      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

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

      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. 

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



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

      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 and RAS. RTP traffic is handled by STUN/TURN/ICE as outlined above.

      The solution for RAS is to get rid of it altogether wink

      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.

      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 screenshot.png 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 screenshot.png H.323/TLS). For a complete list of supported options see fish-help.png IP4/ETH/DHCP-Server.

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


      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

      • /PBX0/APPS
      • /PBX0/web/js
      • /fonts

        Reporting


        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)
        The URL to allow when you use the PBX Call-Lists service for call lists is
        • /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)
        • /classes
        • /style_inno.css
        • /style.css
        • /java_main.js
        • /images
        • /favicon.ico

          If you want to allow external PBXs to post CDRs to the reporting service, you must allow the URL

          • /ap/cdr.fcgi

          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

          • /PBX0/user.soap

          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

          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.

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

          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 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 screenshot.png 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 fish-help.png Security works with innovaphone for 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.

          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 traffic from extern (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 enrypt/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.