How to setup your system for access from/through the internet

About this book

This book talks about setting up a reverse proxy from a practical point of view. As such, it talks mostly about how to set it up, not so much about why. While this is sufficient for setting up the system, a deeper understanding of how these things work is useful when it comes to troubleshooting. This is provided by the previous book Public Access to PBX Resources (Theory) - optional.

And as you know, you won't have the luxury to delve into concepts once it's time to troubleshoot. So we recommend to do it now

Providing access

When PBX resources shall be accessible externally (that is, from outside your local network), incoming and outgoing traffic must be able to flow between all participants.

Let's see which building blocks we have.

Port forwarding

When a device which is part of the PBX system is located outside the private network of the PBX (for example, a

mobile phone with mobile internet access Screenshot: mobile phone with mobile internet access - Course_Data/Reverse_Proxy/rp-01-port-forwarding.png

Screenshot: mobile phone with mobile internet access - Course_Data/Reverse_Proxy/rp-01-port-forwarding.png

), it can not connect to the devices within the private network (e.g. the PBX) directly.

This is because the devices in the private network are hidden behind the internet router (and/or possibly a firewall). However, the external device can connect to the router itself (as the router has an external interface with an accessible public IP address). The router in turn can use a technique called port forwarding to forward connections to a specific TCP or UDP port. With port forwarding, incoming data on a specific port is forwarded to a device within the private network (hence the name). The router can do this, cause it has also an internal interface with a locally accessible private IP address.

Port forwarding must be

configured in the router Screenshot: configured in the router - Course_Data/Reverse_Proxy/rp-01-port-forwarding-http.png

.

Reverse proxy

There are some issues with port forwarding though.

Selective forwarding

First of all, port forwarding will forward all traffic that matches the port specification. For example, if HTTP is forwarded to the PBX, every HTTP request that comes from the internet is sent to the PBX. This of course also includes malicious attackers. You don't want that. So you need a technique to limit the forwarded data to legitimate requests.

But there is another issue. Let's assume we do have an application platform in addition to the PBX. Clients need to establish HTTP(S) connections to both the PBX and to the AP. Both are using ports 80/443. So port forwarding would send all traffic to either the PBX or the AP but there is

no way to differentiate.

One solution would be to configure all clients so that they would use non-standard ports (e.g. port 443 towards the PBX and 444 to the AP). But this clearly results in a

messy and hard to maintain setup.

A technique is needed that is able to forward connections based on the content. In our example, this technique would look into requests and forward those directed to hq-dvl-ckl2.training.innovaphone.com to the PBX and those directed to apps-dvl-ckl2.training.innovaphone.com to the AP.

Reverse proxy

Both issues are fixed using a network entity known as reverse proxy. It is part of the innovaphone operating system and therefore available on all gateway platforms. The reverse proxy

receives connections from the internet router via port forwarding Screenshot: receives connections from the internet router via port forwarding - Course_Data/Reverse_Proxy/rp-01-port-forwarding-http-ap-rp.png

Screenshot: receives connections from the internet router via port forwarding - Course_Data/Reverse_Proxy/rp-01-port-forwarding-http-ap-rp.png

and is able to filter legitimate requests and forward them to the appropriate target.

The reverse proxy

listens on the ports used by the protocols it handles (HTTP/S, H323 TCP/TLS, SIP/S, LDAP/S, SMTP/S)
incoming connections are immediately accepted (that is, the TCP connection is terminated locally on the reverse proxy)
incoming data is buffered and looked at until a routing decision can be taken (deep packet inspection)
if there is a defined target for the incoming connection, a new connection is established to the target service (e.g. the PBX)
if this connection is accepted and not disconnected immediately, the original connection is kept and all traffic is passed back and forth between the two ends
otherwise, the original connection is closed
if a requester sends too many rejected connection establishments in a period of time, the requester is put on a black-list for a while
requests from requesters on the black-list are rejected no matter what

The reverse proxy's configuration defines

a port to listen to for each protocol (protocols where no port is defined are not used by the RP at all)
a set of conditions the incoming request must match. The exact nature of the condition(s) depends on the protocol (we'll see that later)
a target (IP address and port) for each local connection depending on the fulfilled condition

Outgoing connections

While we have seen that both port forwarding and a reverse proxy are required for incoming requests, outgoing requests usually do "right away".

Just like your browser is able to reach out for class.innovaphone.com, your SIP trunk (using its SBC function) is able to connect to your SIP provider. Note that your SIP trunk always connects to your SIP provider, not the other way round (except for the rare case where the provider works in a non-registered mode).

It is good to understand that outgoing connections

do not pass through the reverse proxy Screenshot: do not pass through the reverse proxy - Course_Data/Reverse_Proxy/rp-01-port-forwarding-http-ap-rp-sbc.png

Screenshot: do not pass through the reverse proxy - Course_Data/Reverse_Proxy/rp-01-port-forwarding-http-ap-rp-sbc.png

and also do not require any port forwarding on the internet router.

Media data

Unfortunately,

media data behaves a bit different and therefore other solutions are required (if you feel like digging more in to the details, see Public Access to PBX Resources (theory) - optional: Media and NAT for a more in-depth discussion).

The media data protocol (RTP) uses UDP and is essentially connectionless. No reverse proxy solution can be applied therefore.

When one peer has a public IP address (such as a SIP provider or the mobile phone in our example), then the solution is rather simple: the peer within the private network (e.g. the IP phone) sends data to the mobile phone (which is possible just like you are able to send data to class.innovaphone.com). The internet router sends the packets to the public IP address of the mobile phone and employs a technique called NAT, which replaces the source IP address (the private IP address of the IP phone) with its own public IP address and the source port with some random (but unique) port. When the mobile phone sends back data, the internet router forwards it back to the IP address and port where the original data packet came from. Every internet router has this function.

STUN

Unfortunately, this doesn't work when

peers within two different private networks need to communicate. Neither of the phones have a public IP address the data could be sent to.

The solution is to find out the public IP addresses of the respective internet routers and to send the data there instead. To find out these addresses, a service called STUN is used. A STUN server resides in the internet (that is, it has a public IP address). Both phones would first

send a request to the STUN server Screenshot: send a request to the STUN server - Course_Data/Reverse_Proxy/rp-01-rtp-2-private-stun.png

that allows them to find out the public IP address of their respective routers. These addresses are then exchanged (using the SIP or H.323 signalling, not RTP) and both phones now know where to send their data to.

A STUN server is required and it must have a public IP address. Different peers can use the same STUN server or use different STUN servers.

Usually, your SIP provider will run a STUN server that you can use.

It is not a good idea to use innovaphone's STUN server. Although this server would yield the same results, there is no guarantee of availability. Your ISP or SIP provider's STUN should do better.

TURN

Again, unfortunately, the STUN approach may work or it may not, depending on the type of internet routers used on both ends. For a 100% reliable solution, an additional technique called TURN is used.

A TURN server is an accessible server (also available as part of the innovaphone operating system) where both peers send their media data to. The TURN server then would shovel the data back and forth between the two peers.

The TURN server is usually run by yourself (as opposed to the STUN server). It would be

located in one of the customers locations Screenshot: located in one of the customers locations - Course_Data/Reverse_Proxy/rp-01-rtp-2-private-turn.png

Screenshot: located in one of the customers locations - Course_Data/Reverse_Proxy/rp-01-rtp-2-private-turn.png

(usually the headquarters).

In this scenario it is essential that all peers use the same TURN server.

While TURN theoretically can forward RTP data between multiple TURN servers if clients participating in the same call use different TURN servers, they would suffer from the original RTP problem they are employed to fix (that is, RTP transfer between these TURN servers fails due to the same issues the RTP transfer between the participating endpoints fails in the first place). However, in larger scenarios it is possible to use multiple TURN servers

provided that all of them have a public IP address (that is, reside in the internet). This requirement is usually hard to fulfill for customers.

More precisely, the two TURN servers would need to be able to talk RTP together. This could be possible even if they are not both located in the internet with public IP address (for example, it would work if both are located in the same private network segment).

STUN/TURN/RTP and Firewalls

You obviously need to configure your firewalls in all of your locations to allow at least STUN and TURN. You probably also want to allow RTP so that TURN does not need to be used in most cases.

However, there is one scenario where you have no control over the firewall configuration: when foreign users are using web access to your conferences. In this case, chances are that neither RTP nor both STUN and TURN will be allowed from the foreign users' location due to their firewall policies. In this case, you will need to use an additional fallback TURN server that works on TCP/443 instead of the default UDP/3478 and configure it as a TURN fallback in the conferencing web service. See Public Access to PBX Resources (theory) - optional: TURN on port 443 for some more detail.

Checking the candidates in myApps

myApps has a nice tool to help see which STUN/TURN will be used. For this, you need to configure and start the softphone App. You can then

see the result of an ICE negotiation

in the settings and verify that it matches your expectations (especially the SRFLX (STUN) and RELAY (TURN) candidates cause those depend on your correct configuration).

Summary

In order for the system to work properly, you must use proper STUN and TURN server!

The full picture

To provide external access, we end up with the

complete picture Screenshot: complete picture - Course_Data/Reverse_Proxy/rp-total.png

of components required.

Looks more difficult as it is, because you can run the PBX, TURN server, reverse proxy and SBC on the same innovaphone box!

That simplifies

the picture Screenshot: the picture - Course_Data/Reverse_Proxy/rp-total-simplified.png

quite a bit

Consolidation of services on one box is of course not a yes/no question. All variations are possible from "all-in-one-box" to "each-service-its-own-box".

One common setup is to

have the PBX in the private network and one additional box that runs SBC, reverse proxy and TURN server in a DMZ.

Port conflicts

But hey, wait a moment.

As we said before, the reverse proxy listens for HTTP(S), SIP(S), LDAP(S), H323-TCP/TLS and SMTP(S) requests. In the "all-in-one-box" solution, the PBX would run along with the reverse proxy and it also uses H.323-TCP/TLS, SIP(s), LDAP(S) and HTTP(S). So don't we have a conflict when we run it on the same box?

Yes indeed!

This is why the RP must be configured to listen on non-standard ports for all services when it runs on a box where a PBX runs.

To make it simpler, you just configure it to use non-standard ports always (although it is not strictly required when it runs standalone), whenever it receives its requests from a router using port-forwarding. Of course, if your RP has a public IP address and receives its requests directly, you must configure it using standard ports.

This is relevant for the

port forwarding Screenshot: port forwarding - Course_Data/Reverse_Proxy/rp-port-fiddling.png

you need to configure on your internet router:

clients will send their requests to standard ports (so that you don't have to fiddle around with non-standard protocol ports on all devices)
therefore, your internet router needs port forwardings for standard ports
however, it forwards them to the RP on non-standard ports
the RP listens on those non-standard ports
and forwards requests to the PBX (and other boxes) on the standard ports again
the standard TURN port is forwarded on a standard port directly to the PBX

More details on RP conditions

The exact nature of the conditions that an incoming request must meet in order to be forwarded depends on the protocol.

Generally, there must be a matching Hosts entry with a valid definition where to forward the request to for both encrypted (HTTPS, LDAPS, SIPS, H.323 TLS) and unencrypted (HTTP, LDAP, SIP, H.323 TCP) traffic.

HTTP

HTTP requests are forwarded based on the Host: and GET header found in the request. For example, when you send an HTTP GET request to the RP that is destined for http://hq.dvl-ckl2.net/somepath then it would contain headers such as

GET /somepath

Host: hq.dvl-ckl2.net

For this request to be forwarded, there must be a

rule for Host hq.dvl-ckl2.net with an http://<host> entry that matches /somepath.

The defined URLs are evaluated against a requested URL as follows:

one of the defined URLs 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

In our example, entries like "/somepath", "/some", "/" or "" would be good. Note that an entry with an empty path matches any path (due to the head match). If you want to specify a rule that only matches if an empty path is present in the request, you need to

tick the Default check-mark.

H.323

H.323 requests are forwarded based on the gatekeeper id found in the incoming request. This is a variation of the System Name (a.k.a. domain) found in the PBX/Config/General tab of the advanced UI as follows:

the gatekeeper id has the format [physical-location@]domain[/registration-location]
(both physical-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 physical-location specifies the (geographic) place where a user's device resides. The registration-location however specifies the PBX where the user's registration takes place. Often these two locations are identical but they don't need to be. These concepts are discussed in more detail in the Master-Slave Operation topic which is part of the Plus subscription.

For example, in our scenario a registration sent to the master pbx (hq) for a user who is on the slave pbx (branch-b) will be redirected towards the slave PBX with a gatekeeper id of

hq@dvl-ckl2.net/branch-b

The RP would ignore the physical location so its routing decision is done based on the name

dvl-ckl2.net/branch-b

The registration location (/branch-b) is ignored by the PBX so it uses only the optional physical location and the domain (hq@dvl-ckl2.net) when registering the endpoint.

This way, a request with gatekeeper id dvl-ckl2.net/branch-b can be routed differently from a request with gatekeeper id dvl-ckl2.net although both are treated the same by the PBX.

In our scenario (both the master PBX and the slave PBX are located in the same private network and hence serviced by the same RP), you would specify

two separate Hosts entries:

the first for dvl-ckl2.net, forwarding to the master PBX (172.31.31.2)
the second for dvl-ckl2.net/branch-b, forwarding to the slave PBX (172.31.31.3)

For orthogonality, you may even want to create

a third entry for dvl-ckl2.net/hq, which is a duplicate of the dvl-ckl2.net entry (as far as H.323 is concerned). This entry would be used for example when the slave PBX redirects a registration for a user who is on the master PBX

SIP

SIP requests are forwarded based on the domain part of the URI in the From: header found in REGISTER and INVITE messages.

LDAP

LDAP requests are routed based on the domain part of the user found in the BIND request.

The user 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 (innovaphone.com in this example).

SMTP

SMTP requests are forwarded by looking at the initial protocol exchange. Unfortunately, as SMTP has come a long way over the years, there are quite a number of information elements that need to be considered. So here are the elements that are looked at (and the first one found that matches an existing host entry is taken):

SNI.
If the connection is made using TLS and the client sends an SNI, this is examined
EHLO hostname.
The client hostname found in the EHLO message is examined
AUTH.
If there is an AUTH PLAIN login, the username is examined
RCPT-TO.
Finally, both the full recipient address and the domain part of the recipient address are examined

DNS

We need to touch one last issue: how to set up DNS correctly.

For practical reasons you want all devices to be configured the same way. For example, devices that shall register with the master PBX shall use dvl-ckl2.net as Gatekeeper ID (System Name) and hq-dvl-ckl2.training.innovaphone.com as Primary Gatekeeper, no matter where they are. However, as we have seen in the previous chapters, we want devices within the local network to connect to the PBX directly and others to connect remotely through the reverse proxy instead.

Let us look at a

simple scenario Screenshot: simple scenario - Course_Data/Reverse_Proxy/rp-dns-intern-extern.png

where two IP phones A (local to the PBX) and B (remote) need to register with the master PBX. The master PBX has the domain name hq-dvl-ckl2.training.innovaphone.com. So this is configured as Primary Gatekeeper on all devices.

IP Phone A should connect to the PBX directly, so the DNS name hq-dvl-ckl2.training.innovaphone.com should resolve to the master PBX's private network IP address.

IP Phone B however must connect to the PBX through the reverse proxy. As the RP is not directly reachable for IP Phone B, the registration must be sent to the public IP address of Internet Router A. So for IP Phone B, the DNS name hq-dvl-ckl2.training.innovaphone.com must resolve to the master PBX's private network IP address. How that?

The miracle here is to

deploy additional internal DNS servers for each location with local resources. They are configured such that locally available devices resolve with their local IP address. All other name requests are forwarded to the official DNS and resolve to the respective public IP address.

Where to run the internal DNS

Popular choices are to use the DNS in your active directory or just any innovaphone gateway platform.

Note however that this DNS must be used not only by all telephony devices but also by all PCs running myApps.

How to make sure devices are using the "right" DNS?

DNS settings most likely come along as a DHCP option. That is, within your private network, you need to make sure DHCP delivers a DNS Server 1 option that points to your local internal DNS.

Devices in the wilderness of the public internet will get their DNS server setting from their internet provider. This will be a public DNS server that will use the definitions of your official DNS, which is exactly what you want in this case.

You could be tempted to add both the internal and the external DNS as value for DHCP option 6 (DNS) so that the external DNS is used as a secondary DNS. However, specifying multiple DNS servers is like saying "here are some DNS servers, use whichever you like". This of course is not what you want to do.

What if I can't run an internal DNS?

In this case, you can try to run the system with the official DNS only. Local devices would then resolve the names to the official (that is, external) IP addresses so that all local traffic would flow through the local internet router.

There are two drawbacks:

it might just not work
For this to work, your internet router must support hair-pinning. Not all do
it imposes extra (and useless) load on your internet router
In a smaller scenario this is usually not an issue. However, for larger sites, this may create issues

Reverse proxy and certificates

Server certificate validation

As we have discussed before, the reverse proxy would terminate TLS connections itself (and entertain separate own connections towards the target service). For this reason, the "server certificate" seen by the external clients is always the certificate of the reverse proxy (not the certificate of the target service).

Clients usually will validate the CN found in the certificate against the service name they used to connect. For example, a browser which connects to https://hq-dvl-ckl2.training.innovaphone.com/PBX0/APPCLIENT/appclient.htm will expect to see hq-dvl-ckl2.training.innovaphone.com in the certificate. The device certificate of the reverse proxy should therefore contain all those DNS names as Subject Alternate Names (SAN) entries.

The Connector for Let's Encrypt helps big time to maintain such certificates

As an alternative, the reverse proxy can use a so-called wildcard certificate (e.g. with *.dvl-ckl2.training.innovaphone.com as subject).

Client certificate validation

The same is true on the other end of the reverse proxy connection (between the reverse proxy and e.g. the PBX). The PBX can validate clients based on the CN found in their certificate (this is actually recommended and the default).

However, the incoming connections for remote clients always originate from the reverse proxy. Therefore, the PBX will always see the reverse proxy's certificate as client certificate and is unable to validate the client based on this. The certificate validation therefore must be done by the reverse proxy!

For this to work, some preconditions must be fulfilled

the reverse proxy must trust the incoming client certificates (that is, their root certificate must be included in the RPs trust list)
the RP rules for H.323 and SIP must always have both the plain and secure target ports defined (for details on this see the Reverse Proxy and PBX Interaction chapter in Public Access to PBX Resources (theory) - optional)
the PBX must have the IP address and certificate CN of its RP set in PBX/Config/General/Reverse Proxy Addresses and the Assume TLS check-mark ticked

Sample scenario

In the remainder of this book, we're working on a sample scenario that involves 2 PBXs (known as master PBX and slave PBX).

In the courses you've done so far, you probably had not covered this type of scenario. If you're interested in all the details of it, we recommend to do the master/slave topic in our Plus course. See

IT Plus Overview for all topics available in Plus courses.

In the context of this book, it is sufficient to understand that instead of handling all users on a single PBX (more precisely, on a single device running the PBX), you can have multiple devices running separate instances of the PBX and distribute your users among these PBXs.

This makes sense, for example, if these instances are in different locations for geo-redundancy. You would then configure the system so that all users are served by their local PBX. However, if one PBX fails, its users would be handled by the remote PBX instead.

master-slave Screenshot: master-slave - Course_Data/Reverse_Proxy/master-slave.png

Not all the details of how this works are of interest for this topic. For this reason, both the master and slave PBX are already configured in the startup configuration. Instead, we will focus on how this scenario affects the reverse proxy configuration.

So this is a good time to load the start configuration ReverseProxy.

After all devices have loaded the new start configuration (the Last Loaded Base Configuration column on the Devices page shows Reverse Proxy (auto) for all devices and the Lesson Checker is complaining about the AP reachable or Proper events App data loaded test) you need to upload the AP configuration.

See How to setup the Application Platform after a factory reset for how to do that.

The complete reference

To implement our

master-slave sample scenario in the training setup, we need to modify the

full public access scenario as discussed in chapter The full picture above:

we remove the phone in remote network (IP Phone B) as we do not have this in our training
master PBX, RP for location hq, TURN server and SBC run on the IP411LEFT (172.31.31.2)
the AP runs on the IP411LEFT (172.31.31.12)
a slave PBX and RP for location branch-b is running on the IP811 (172.31.31.3)
we use your trainee network (that is, the network you plugged your IP411RIGHT into) to simulate the internet
your internet router for hq is the IP411RIGHT (172.31.31.2 with a fictitious public IP address 172.100.0.1)
we simulate an official DNS on the IP411RIGHT
we simulate an internal DNS for location hq on the IP411LEFT
we simulate an internal DNS for location branch-b on the IP811

For this exercise, we need to modify the standard setup found in the field a little bit. Instead of assuming that branch-b is in a remote location (which obviously is a typical characteristic of a branch), we need to implement it in the same private network as the head-quarters (that is, in your trainee network 172.31.31.*).

While this may seem a bit unrealistic to you (which is true), there is a more or less good reason to do so: we do not have enough gateway platforms to implement 2 PBXS, 2 RPs and 2 internet routers

. This has the following consequences:

both master and slave PBX are located in the same private network (hence behind the same internet router)
your internet router for branch-b (with a fictitious public IP address of 172.200.0.1) does not exist, as we do not have enough devices. We therefore route IP traffic for branch-b also through 172.100.0.1 (the IP411RIGHT) to the RP at 172.31.31.2 which also handles branch-b.

This of course is not what happens in a real-life scenario. In a real-life scenario, the IP traffic would be sent though branch-b's internet router (172.200.0.1) to branch-b's RP (172.31.31.3). Sounds a bit confusing but in fact it does change the configuration only slightly - we'll come back to these details later on
as we have only one internet router (the IP411RIGHT), we can only forward IP traffic to one location behind it. We will forward packets to the hq RP. In other words: the RP in branch-b will never be used, instead the RP on hq must implement the settings for branch-b too
devices in location branch-b will send traffic for devices in location hq to hq's internet router, which is the IP411RIGHT. As this is also the internet router for branch-b itself, we use hairpinning here (that is, packets sent to the external IP of the IP411RIGHT will be forwarded back to the hq devices through the same network (which is your trainee network))
finally, we omit the SIP trunks as it adds complexity but does not change any of the mechanisms discussed in this book

We then end up with this

modified setup Screenshot: modified setup - Course_Data/Reverse_Proxy/training-scnenario-with-hairpinning.png

.

The remainder of this chapter is the complete reference.

We'll walk through all required configuration in the following chapters.

Port forwardings on your internet router

Service	Protocol	Port	Destination address Address	Destination port Int. Port (optional)
TURN	UDP	3478	TURN server on IP411LEFT 172.31.31.2	+
TURN	TCP	3478	TURN server on IP411LEFT 172.31.31.2	+
HTTP / WS§	TCP	80	RP on IP411LEFT 172.31.31.2	90*
HTTPS / WSS§	TCP	443	RP on IP411LEFT 172.31.31.2	453*
LDAP	TCP	389	RP on IP411LEFT 172.31.31.2	399*
LDAPS	TCP	636	RP on IP411LEFT 172.31.31.2	646*
SIP#	TCP	5060	RP on IP411LEFT 172.31.31.2	5070*
SIPS#	TCP	5061	RP on IP411LEFT 172.31.31.2	5071*
H.323 TCP	TCP	1720	RP on IP411LEFT 172.31.31.2	1730*
H.323 TLS	TCP	1300	RP on IP411LEFT 172.31.31.2	1310*
§ WS/WSS may differ from HTTP/HTTPS when using a firewall # only required if SIP endpoints are used, not for SIP trunks + standard port used, can be left empty * non-standard port used by RP

As you can see, inbound port forwarding is done towards the RP and TURN server only. An SBC will only do outbound connections (except very rare cases) and a STUN server cannot be run meaningfully inside your local network. Also, all forwarding towards the TURN server is done using the standard port whereas all forwarding towards the RP is done towards a non standard port.

If you intend to use a separate box for the RP and/or TURN server (e.g. one located in the DMZ), then you would forward to this box instead.

STUN/Turn settings

Setting	Recommended Value	Remark	*Created OK by Install?*
STUN server	STUN server provided by your SIP provider	You should avoid using stun.innovaphone.com as there is no service level agreement in place if you do so
TURN server	hq-dvl-ckl2.training.innovaphone.com	The Install has set up a TURN server on your master PBX
TURN username	your-choice	Your TURN server should not be used by 3rd parties easily, so better use a strong password
TURN password	your-choice

using hq-dvl-ckl2.training.innovaphone.com as DNS name for the TURN server implies that the TURN server runs on the master PBX. Local clients would resolve that to the local IP address of the master PBX, remote clients would resolve it to the external address of the headquarters internet router (from where it would be port-forwarded to the master PBX).

If you intend to use a separate box (e.g. one located in the DMZ) for your TURN server (as well as possibly for your RP and SBC), then you should introduce a new DNS name turn-dvl-ckl2.training.innovaphone.com.

DNS settings

DNS names in the official DNS

If you have a fixed IP address

Remark	Type of entry	Name	Value
router hq	A	router-hq-dvl-ckl2.training.innovaphone.com	172.100.0.1§
router branch-b	A	router-branch-b-dvl-ckl2.training.innovaphone.com	172.200.0.1#
master PBX	CNAME	hq-dvl-ckl2.training.innovaphone.com	router-hq-dvl-ckl2.training.innovaphone.com
AP	CNAME	apps-dvl-ckl2.training.innovaphone.com	router-hq-dvl-ckl2.training.innovaphone.com
slave PBX	CNAME	branch-b-dvl-ckl2.training.innovaphone.com	router-branch-b-dvl-ckl2.training.innovaphone.com
			§ external address of hq's internet router # external address of branch-b's internet router

The A entries for router-hq.dvl-ckl2.net and router-branch-b.dvl-ckl2.net are not strictly required (you could simply change the CNAME entries to A entries pointing directly to 172.100.0.1 and 172.200.0.1, respectively):

Remark	Type of entry	Name	Value
master PBX	A	hq-dvl-ckl2.training.innovaphone.com	172.100.0.1§
AP	A	apps-dvl-ckl2.training.innovaphone.com	172.100.0.1§
slave PBX	A	branch-b-dvl-ckl2.training.innovaphone.com	172.200.0.1#
			§ external address of hq's internet router # external address of branch-b's internet router

But we feel that using CNAMEs is clearer and also better manageable once you change IP addresses.

Unfortunately, in this topic when we use the IP411RIGHT as DNS server, we need to use the second version as the innovaphone server does not support CNAME entries at all (however, our DNS client does!).

If you don't have a fixed IP address

When you need to use DynDNS, the table is only slightly different.

Remark	Type of entry	Name	Value
router hq	CNAME	router-hq-dvl-ckl2.training.innovaphone.com	yourhost-hq.yourdyndns.tld
router branch-b	CNAME	router-branch-b-dvl-ckl2.training.innovaphone.com	yourhost-branch-b.yourdyndns.tld
master PBX	CNAME	hq-dvl-ckl2.training.innovaphone.com	router-hq-dvl-ckl2.training.innovaphone.com
AP	CNAME	apps-dvl-ckl2.training.innovaphone.com	router-hq-dvl-ckl2.training.innovaphone.com
slave PBX	CNAME	branch-b-dvl-ckl2.training.innovaphone.com	router-branch-b-dvl-ckl2.training.innovaphone.com

Your DynDNS provider then would have the following setting in its own DNS:

Remark	Type of entry	Name	Value
router hq	A	yourhost-hq.yourdyndns.tld	172.100.0.1§
router branch-b	A	yourhost-branch-b.yourdyndns.tld	172.200.0.1#
			§ external address of hq's internet router # external address of branch-b's internet router

We're not going to use DynDNS in this course though.

DNS names in the internal DNS for hq

Remark	Type of entry	Name	Value
master PBX	A	hq-dvl-ckl2.training.innovaphone.com	172.31.31.2
AP	A	apps-dvl-ckl2.training.innovaphone.com	172.31.31.12

DNS names in the internal DNS for branch-b

Remark	Type of entry	Name	Value
slave PBX	A	branch-b-dvl-ckl2.training.innovaphone.com	172.31.31.3

If you run a separate TURN server

If you intend to use a separate box for TURN (e.g. one located in the DMZ), then you need another DNS name turn-dvl-ckl2.training.innovaphone.com.

You would define it in the official DNS to point (most probably) to your headquarters' internet router (although it could of course be located in just any other location you have):

Remark	Type of entry	Name	Value
TURN	CNAME	turn-dvl-ckl2.training.innovaphone.com	router-hq-dvl-ckl2.training.innovaphone.com

In addition to that, you would add an entry in the headquarters' (or wherever you placed your TURN server) internal DNS that points to your extra box:

Remark	Type of entry	Name	Value
local TURN	A	turn-dvl-ckl2.training.innovaphone.com	local-ip-of-your-turn-server

The Install does not create any of these entries. This is because in real-life, you would probably use your existing DNS infrastructure for this.

Firewall settings

Firewall settings can get complex and depend on your actual network setup. We are not going to discuss this in any detail in this course, but you may refer to

Firewall Settings for details.

Reverse Proxy settings

In our scenario, we have 2 RPs: one on the master PBX in hq and one on the slave PBX in branch-b.

Service Ports

In our scenario, the RPs run on the PBX in both sites and therefore must listen on non-standard ports (so as to not conflict with the PBX services) and forward to standard ports.

In theory, you could use just any non-standard port but we recommend to use those that are also suggested by the Reverse Proxies Settings App plugin when

Set standard ports (public IP) is not ticked.

Service	TCP Port	TLS Port	Remark
H.323	1730	1310	All services accepted on standard port + 10
SIP	5070	5071
LDAP	399	646
HTTP	90	453

These port settings are the same for all RPs in all locations.

In a real-world (not training) scenario, if you choose to run the RP on a dedicated box (e.g., in a DMZ), you could forward to standard ports (since there would be no port conflicts on that box). However, for simplicity and uniformity, you may still want to use non-standard ports. This way, the configuration of your RPs and Internet routers will be similar in all locations.

Further global settings are as follows:

Setting	Recommended Value	Remark	Created by PBXManager?
No IPv4	off	This flag disables IPv4 for the reverse proxy
No IPv6	off	This flag disables IPv6 for the reverse proxy
Log Forwarded Requests	off	No normal logs should be turned on unless you are debugging an issue
Log Rejected Requests	on	To see issues in the Logging App
Blacklist Expiration (min)	5	To avoid manual intervention if a client ends up in the blacklist for whatever reason
Suspicious Requests/min	20
Public NAT router address	172.100.0.1 / 172.200.0.1	must be set for incoming SIP requests to the public address of your NAT router, depending on the location (remember that 172.100.0.1/172.100.0.1 must be replaced by your internet routers IP address). You can leave this field empty if the RP also performs the NAT router function. If your NAT router offers different SIP ports (default 5060 and 5061), then you have to specify the port to be used. Since only one port can be specified, only either SIP/TCP or SIP/TLS will work. only if SIP is required (e.g. 3rd party devices). SIP trunks do not require this!

Hosts

As we already discussed before, the RP in branch-b won't be used at all as we do not have an internet router in branch-b which would forward traffic to this RP. Instead, all traffic is forwarded to the RP in hq and we will configure the host entries that are required for branch-b on the RP in hq. In real life however, you would obviously configure the entries required for branch-b on the RP in branch-b.

The following forwarding rules must be created.

Hosts for hq

apps-dvl-ckl2.training.innovaphone.com

This is used for HTTP and LDAP access to your application platform. No other service types should be forwarded.

Service	Path	*Target (Out)*	TCP Port	TLS Port	Remark	Created by PBXManager?
H.323					not forwarded
SIP					not forwarded
LDAP		172.31.31.12	389	636	to access Contacts, e.g. with a bind user apps-dvl-ckl2.training.innovaphone.com\contacts
HTTP		172.31.31.12	80	443	wildcard, e.g. https://apps-dvl-ckl2.training.innovaphone.com

hq-dvl-ckl2.training.innovaphone.com

This is used for LDAP and HTTP access to your master PBX. No other service types should be forwarded (remember that H.323 and SIP is forwarded based on the gatekeeper id, not the DNS name). The settings are essentially the same for all master and slave PBXs, except for the target server IP address.

Service	Path	*Target (Out)*	TCP Port	TLS Port	Remark	Created by PBXManager?
H.323					not forwarded
SIP					not forwarded
LDAP		172.31.31.2	389	636	to access the master PBX LDAP, e.g. with a bind user hq-dvl-ckl2.training.innovaphone.com\ldap-guest
HTTP	/PBX0/APPCLIENT/appclient.htm	172.31.31.2	80	443	myApps client, e.g. https://hq-dvl-ckl2.training.innovaphone.com/PBX0/APPCLIENT/appclient.htm
HTTP	/PBX0/APPS	172.31.31.2	80	443	PBX apps
HTTP	/PBX0/session.	172.31.31.2	80	443	myApps two-factor authentication
HTTP	/PBX0/user.soap	172.31.31.2	80	443	only if TAPI or SOAP API is used
HTTP	/OAUTH2/oauth2_login	172.31.31.2	80	443	only if OAuth2 authentication is used

dvl-ckl2.net

This is used for H.323 and SIP access to your master PBX (and optionally for LDAP). No other service types should be forwarded.

Service	Path	*Target (Out)*	TCP Port	TLS Port	Remark	Created by PBXManager?
H.323		172.31.31.2	1720	1300	Check Certificate must be ticked e.g. to register at the master PBX with a gatekeeper id location@dvl-ckl2.net or dvl-ckl2.net
SIP		172.31.31.2	5060	5061	only if SIP registration is required (e.g. 3rd party devices). SIP trunks do not require this! Check Certificate must be ticked e.g. to register at the master PBX with a From: address user@dvl-ckl2.net
LDAP		172.31.31.2	389	636	to access the master PBX LDAP, e.g. with a bind user dvl-ckl2.net\ldap-guest
HTTP					not forwarded

Note that the LDAP entry here is redundant to the LDAP entry for hq-dvl-ckl2.training.innovaphone.com. It is a convenient short-hand for addressing the LDAP server on the master PBX. However, being a redundant shorthand, it is optional.

Hosts for branch-b

Note that the Settings App cannot create all valid RP entries for a slave PBX. You need to create some of them manually.

branch-b-dvl-ckl2.training.innovaphone.com

This is used for HTTP and LDAP access to your slave PBX. No other service types should be forwarded (remember that H.323 and SIP is forwarded based on the gatekeeper id, not the DNS name).

Service	Path	*Target (Out)*	TCP Port	TLS Port	Remark	Created by PBXManager?
H.323					not forwarded
SIP					not forwarded
LDAP		172.31.31.3	389	636	to access the slave PBX LDAP with a bind user branch-b-dvl-ckl2.training.innovaphone.com\ldap-guest
HTTP	/PBX0/APPCLIENT/appclient.htm	172.31.31.3	80	443	myApps client, e.g. https://branch-b-dvl-ckl2.training.innovaphone.com/PBX0/APPCLIENT/appclient.htm
HTTP	/PBX0/APPS	172.31.31.3	80	443	PBX apps
HTTP	/PBX0/session.	172.31.31.3	80	443	myApps two-factor authentication
HTTP	/OAUTH2/oauth2_login	172.31.31.3	80	443	only if OAuth2 authentication is used
HTTP	/PBX0/user.soap	172.31.31.3	80	443	only if TAPI or SOAP API is used

dvl-ckl2.net/branch-b

This is used for H.323 and SIP access to your slave PBX. No other service types should be forwarded.

The Settings App will not create this entire host entry, so you need to configure it yourself.

Service	Path	*Target (Out)*	TCP Port	TLS Port	Remark	Created by PBXManager?
H.323		172.31.31.3	1720	1300	Check Certificate must be ticked e.g. to register at the slave PBX with a gatekeeper id location@dvl-ckl2.net/branch-b or dvl-ckl2.net/branch-b
SIP		172.31.31.3	5060	5061	only if SIP registration is required (e.g. 3rd party devices). SIP trunks do not require this! Check Certificate must be ticked e.g. to register at the slave PBX with a From: address user@dvl-ckl2.net/branch-b
LDAP					not forwarded
HTTP					not forwarded

Custom certificates

For the whole thing to work properly, you need to install custom certificates to your system. Read Custom certificates for more details.

For most installations, the Connector for Let's Encrypt can be used to obtain certificates for your devices.

We've already done this in the topic "A look at the system architecture" (see chapter Let's Encrypt in Setting up the Apps: Let's Encrypt). However, it certainly does not hurt to go through it again.

So, in this chapter, let's take a look again at how it all works.

Installing the connector

To do this configuration, you need to login to myApps (http://hq-dvl-ckl2.training.innovaphone.com/PBX0/APPCLIENT/appclient.htm?lang=en) and login as user ckl with password ip411).

This is easily done using the AP app installer plugin in the Settings App .

To install the connector, proceed as follows:

start the Settings App App
start the AP app installer plugin
type encrypt in to the search field on the upper right
click on Connector for Let's Encrypt
select the srTraining version
accept the terms of use
when the installation is done, close the entire Settings App App
and start it again. You will see a new AP letsencrypt entry.

If the AP letsencrypt entry is missing, it is probably because either the instance or the entire service does not run. In this case, open the AP Manager and start both the service and the instance.

The connector is installed now and needs to be configured.

Here is how:

click on the new AP letsencrypt icon
open the Settings area
tick the Enable check-mark
leave the Let's Encrypt directory URL as is (but see below!)
agree to the subscriber agreement
set a Client password
This password is the password all client devices (that is, the devices which shall receive a certificate) need to know. The connector is a bit picky here, so we cannot use our usual password here. Instead, in this course, use ip411ip411
you can leave the value for Certificate installation before expiry (days) as is (which is 3)

The remaining two fields are (Client URL and URL for Let's Encrypt root certificates) are for information only. We will need them whenever we configure a device to receive a certificate.

In a real-life installation, that would be it. However, here in the training we want to make sure that Let's Encrypt won't create real production certificates.

This is done by changing the Let's Encrypt directory URL to the URL of their staging environment: https://acme-staging-v02.api.letsencrypt.org/directory.

Using the LE staging environment ensures that we do not run into problems caused by misconfiguration (e.g. throttling imposed by LE if too many certificates are requested). On the other hand, LE will issue certificates that are not signed by a known CA. Your browser will therefore not trust these certificates unless you have manually added them to the browser's trust list (e.g. when accessing myApps with https). This is only an issue if you are using the staging environment. In real life this won't be necessary!

Requesting a certificate for your AP

As you can

see in the AP's Settings / Security menu (accessible from the Burger menu), your AP still has the hard-wired default certificate installed.

To change that, we need to configure the Let's Encrypt client on the AP as follows (use the AP manager App for this)

go to Settings / Let's Encrypt (accessible from the burger menu)
tick the Enable check-mark
set the Let's Encrypt App URL to the service URL of your Connector for Let's Encrypt App instance: wss://apps-dvl-ckl2.training.innovaphone.com/dvl-ckl2.net/letsencrypt/clients

You can copy this from the Client URL field in the AP letsencrypt Settings App plugin
set the Let's Encrypt App Password to the value you have set as Client password in the Let's Encrypt App service instance configuration (didn't you take note of it? never mind, it is ip411ip411)
set the Key length (bit) to 2048 bits. Never use another value unless you really know what you do

This is because changing the certificate's key length to a higher value would impact the performance of your system significantly, as it slows down each and any TLS connection establishment
set the DNS name(s) to the DNS name of your AP: apps-dvl-ckl2.training.innovaphone.com
hit the Save button. Make sure there is no The changes have failed message near to the button. If so, make sure you filled in all the fields (including selecting the 2048bit key length)

The DNS name must be functional in your DNS system and must point to a device that allows external TCP access to the device for which the certificate is intended on port 80 (HTTP). LE will use this DNS to connect to it, thus verifying that you are the owner of this DNS domain. In practice, this will probably be your Internet router with port forwarding or a reverse proxy.

It's a good time to have a cup of coffee now (well then, perhaps better an even quicker espresso) until you see the

new device certificate appearing in burger menu / Settings / Security.

Deploying LE's trust list to all devices

Let's Encrypt will issue officially trusted certificates to your devices. That is, your browser will trust those certificates right away.

However, the innovaphone devices don't have a global trust list. You need to maintain the list of trusted root certificates yourself. This is easily handled using

the Certificates device configuration in the Devices App.

To deploy LE's root certificates to the trust list of all devices, you need to follow these steps:

open the Settings App App
start the AP letsencrypt plugin
click on Settings
copy the content of the URL for Let's Encrypt root certificates field
open the Certificates configuration job editor in the Devices App
add the copied URL to the list of Sources for certificates

You will see the LE root certificate

added to the device's trust list, e.g. in General / Certificates.

Requesting a certificate for the reverse proxy

Our master PBX and RP runs on the IP411-LEFT. Usage of the Connector for Let's Encrypt can be configured in the Services / Letsencrypt tab.

tick the Enable check-mark
copy the Client URL from the Settings App plugin (wss://apps-dvl-ckl2.training.innovaphone.com/dvl-ckl2.net/letsencrypt/clients) into the Let's Encrypt App URL field
type the Client password that you had entered in the Settings App plugin (ip411ip411) into the Let's Encrypt App Password field
leave the Key length as-is
We also recommend that in your real-life projects. Before you consider to use different key length settings, be sure to read section Certificate Key Length and CPU Usage in Certificate management !
add the DNS names of the devices which will be reached through the RP in to the DNS Name table:

hq-dvl-ckl2.training.innovaphone.com
apps-dvl-ckl2.training.innovaphone.com

make sure the Use as CN check-mark is ticket next to the hq-dvl-ckl2.training.innovaphone.com entry (this should always be ticked for the primary DNS name of the device, not for those names that are only added because the device also works as a reverse proxy)

Again, this is now a good time for a (very quick indeed) coffee. After that, you will see the

new device certificate issued by LE in the General / Certificates] tab.

You will notice that both accessing the IP411LEFT and accessing the AP from the browser with HTTPS (i.e. from within myApps) requires you to accept a security warning from your browser.

This is because the certificate issued by LE is not a true good & trusted certificate. It would be if we hadn't specified the staging URL to the Let's encrypt directory. In other words: this issue won't happen in real-life.

Requesting a certificate for the slave PBX

Our slave PBX runs on the IP811. Usage of the Connector for Let's Encrypt can be configured in the Services / Letsencrypt tab.

tick the Enable check-mark
copy the Client URL from the Settings App plugin (wss://apps-dvl-ckl2.training.innovaphone.com/dvl-ckl2.net/letsencrypt/clients) into the Let's Encrypt App URL field
copy the Client password from the Settings App plugin (ip411ip411) into the Let's Encrypt App Password field
leave the Key length as-is
We also recommend that in your real-life projects. Before you consider to use different key length settings, be sure to read section Certificate Key Length and CPU Usage in Certificate management !
add the following name in to the DNS Name table: branch-b-dvl-ckl2.training.innovaphone.com

Again, this is now a good time for a (very quick indeed) coffee. After that, you will see the

new device certificate issued by LE.

Note that LE will issue certificates which are derived from various root certificates. This is why the name you see might differ from (STAGING) Wannabe Watercress R11.

Again, you might notice that both accessing the IP811 and accessing the AP from the browser with HTTPS (i.e. from within myApps) requires you to accept a security warning from your browser.

This is because the certificate issued by LE is not a true good & trusted certificate. It would be if we hadn't specified the staging URL to the Let's encrypt directory.

Finalizing the certificate on the reverse proxy

Now that we have the LE client up and running on the IP811 (our slave PBX), we can finalize the device certificate on the reverse proxy.

To understand why this is necessary, let us recap how access to a device through an RP works.

When an HTTP(S) request is sent to your system (regardless if it is destined for the PBX or the AP), it will be forwarded to the reverse proxy by your internet router (this is why we will configure port forwardings later on the IP411RIGHT).

The reverse proxy will terminate these connections and therefor needs a certificate that lists all of the hosts it is configured to forward connections to. This is because as seen from the client, the RP works on behalf of the final destination. As such, it must therefore present the certificate that identifies it as the final destination during TLS connection establishment.

In our case, these are the names we're using:

hq-dvl-ckl2.training.innovaphone.com
apps-dvl-ckl2.training.innovaphone.com
branch-b-dvl-ckl2.training.innovaphone.com

All of these names must therefore be included in the reverse proxy certificate.

Add the missing name branch-b-dvl-ckl2.training.innovaphone.com in the Services / Letsencrypt tab as an additional name to the DNS Name list.

After a few moments, you can see that the device certificate now

includes the branch-b name.

The magic

You might ask yourself: wait a moment, why is this whole stuff working at all?

After all, Let's encrypt needs to reach our devices for certificate checking. However, reaching the devices from the outside is only possible as soon as we have configured the RP. And this will only be done in the next chapter. So how comes that LE was able to provide us with certificates?

Well, the reason is that the reverse proxy will only provide access into our trainee network from our simulated internet (that is, from your corporate network or from the training network if you are in a training site). It does not actually provide access from the real internet.

For this reason, there is some other magic in place so that LE can reach your devices. If you are a fearless person, you could try to figure out how this is arranged.

However, you can also choose to simply keep in mind that in a real installation, LE certificates would not be obtained until the RP is properly in place.

Let's do it!

Ok, enough theory. Let's do it!

Both the master PBX on your IP411LEFT and the slave PBX on your IP811 are already pre-configured as part of the start configuration you loaded before.

However, no public access is configured so far. For this reason, we have the following issues:

we can call from Jean Dupont (12) to John Doe (10) as the call stays in hq.
But we can not call from John Doe (10) to Lisa Svensson (11) as this call would flow from hq to branch-b
also, we can connect myApps on the mobile phone neither to the master nor to the slave PBX.

So making these things work is our goal for the remainder of this book.

To simulate the mobile phone being in the internet, we

add a WLAN access point Screenshot: add a WLAN access point - Course_Data/Reverse_Proxy/training-scnenario-with-hairpinning-and-WLAN.png

to our setup, so that it connects to the same network segment our IP411RIGHT is connected to through its ETH0 interface (you can open the full scenario in a new tab for reference).

When this is successfully done,

you should be able to determine the mobile phone's IP address (something like 192.168...) as well as the subnet mask (something like 255.255.255.0) and ping to it:

on an iPhone, go to Settings / Wi-Fi
then tap on the little i next to your WLAN name
take note of the IPV4 ADDRESS / IP Address
take note of the Subnet Mask

on an Android, go to Settings / Network & connection
then tap on Wi-Fi
then tap on the network you're connected with
scroll down and take note of the IP address
take note of the Subnet Mask

Port forwardings

Port forwardings need to be set on your (simulated) internet router.

So

open IP4 / NAT / General
to add Port specific forwardings, use the Add new map area and add maps for all relevant protocols which forward to the master PBX (which we intend to use as TURN server and reverse proxy later on), according to the following table

Service	Protocol	Port	Destination address Address	Destination portInt. Port (optional)
TURN	UDP	3478	TURN server on IP411LEFT 172.31.31.2	+
TURN	TCP	3478	TURN server on IP411LEFT 172.31.31.2	+
HTTP / WSÂ§	TCP	80	RP on IP411LEFT 172.31.31.2	90*
HTTPS / WSSÂ§	TCP	443	RP on IP411LEFT 172.31.31.2	453*
LDAP	TCP	389	RP on IP411LEFT 172.31.31.2	399*
LDAPS	TCP	636	RP on IP411LEFT 172.31.31.2	646*
SIP#	TCP	5060	RP on IP411LEFT 172.31.31.2	5070*
SIPS#	TCP	5061	RP on IP411LEFT 172.31.31.2	5071*
H.323 TCP	TCP	1720	RP on IP411LEFT 172.31.31.2	1730*
H.323 TLS	TCP	1300	RP on IP411LEFT 172.31.31.2	1310*
Â§ WS/WSS may differ from HTTP/HTTPS when using a firewall # only required if SIP endpoints are used, not for SIP trunks + standard port used, can be left empty * non-standard port used by RP

This is a hard work after which you deserve a coffee.

Keep in mind that in real-life, this has to be done on your real internet router!

STUN/TURN

The STUN and TURN settings are set globally (that is, for all devices) using the

Media Global device configuration in the Devices App.

To see this configuration, you need to login to myApps (http://hq-dvl-ckl2.training.innovaphone.com/PBX0/APPCLIENT/appclient.htm?lang=en) and login as user ckl with password ip411).

The TURN server has been configured to run in the master PBX by the Install, which is a valid configuration in many cases.

Some settings created by the Install should be changed however according to the table you already have seen:

Setting	Recommended Value	Remark	*Created OK by Install?*
STUN server	STUN server provided by your SIP provider	You should avoid using stun.innovaphone.com as there is no service level agreement in place if you do so
TURN server	hq-dvl-ckl2.training.innovaphone.com	The Install has set up a TURN server on your master PBX
TURN username	your-choice	Your TURN server should not be used by 3rd parties easily, so better use a strong password
TURN password	your-choice

The reason why you don't want to use stun.innovaphone.com as your STUN server is that it is not meant for that. We certainly try our best to keep it available, but there is no guarantee. Your SIP provider will most likely offer its own STUN server, so it's better to use this.

In this course however, innovaphone is your SIP provider, so you can keep stun.innovaphone.com

The reason why you don't want others to use your TURN server is that it would impose network and CPU load on our master PBX. The configuration created by the Install (user turn, password turn.dvl-ckl2.net) is easily guessed!

To fix this

choose a TURN username (in this course, use turn342823)
choose a TURN password (in this course, use ip411 as always)
change the TURN credentials in the Media Global device configuration in the Devices App accordingly. This will make all your STUN client devices use the new credentials
also change the TURN User and Password in the STUN/TURN server settings in IP4 / NAT / General accordingly (be sure to remove the turn user which the Install has created for you)

Reverse proxy

Now that we have forwarded HTTP, LDAP, SIP and H.323 to the reverse proxy, it's time to configure our reverse proxy on the IP411LEFT (our master PBX) so it selectively forwards these requests to the target service.

What the Reverse Proxies Settings App can do

This is a lot of typing and you better don't do a mistake. Fortunately, the Settings App's Reverse Proxies plugin is here to the rescue. It can do most of the work for us.

To do the basic setup

log in to myApps on the master PBX (http://hq-dvl-ckl2.training.innovaphone.com/PBX0/APPCLIENT/appclient.htm?lang=en) using an account that has administration rights and has hq as login-PBX (either john.doe or ckl, both have password ip411)
open the Reverse Proxies Settings App plugin
click on Add a Reverse Proxy to add an RP
A list of options is displayed (the IP411LEFT/master PBX hq, the IP811/slave PBX branch-b and the IP411RIGHT/Router and DHCP Server). As we want to run the reverse proxy on our master PBX, we select the IP411LEFT (master PBX hq)
in the Settings area, we enable all protocols (with Set standard ports (public IP) not ticked, as we want to use non-standard ports for the RP)

Note that these ports correspond to the internal ports (Int. Port (optional)) we used to configure the port forwarding in our (simulated) internet router before
click on Add a host
add both offered hosts
click OK

A

fair amount of configuration has been done by the Settings plugin (you can see that at Services / Reverse-Proxy). There are entries for apps-dvl-ckl2.training.innovaphone.com, dvl-ckl2.net and hq-dvl-ckl2.training.innovaphone.com.

Of course, we need entries for both hq-dvl-ckl2.training.innovaphone.com and branch-b-dvl-ckl2.training.innovaphone.com! Which one is created by the Settings App plugin depends on the PBX you are connected with when you logged-in to myApps. The Reverse Proxies Settings plugin would always suggest an entry for the PBX you are connected to.

The easiest way to create the missing host entry for branch-b-dvl-ckl2.training.innovaphone.com therefore is to log-in to the slave PBX and use the Reverse Proxies plugin there:

Log in to myApps on the slave PBX (http://branch-b-dvl-ckl2.training.innovaphone.com/PBX0/APPCLIENT/appclient.htm?lang=en) using an account that has administration rights and has branch-b as login-PBX (this is lsv (Lisa Svensson) with password ip411). You may need to log out from myApps if you were logged in there before
open the Settings App Reverse Proxies plugin again
click on Add a reverse proxy
select our existing reverse proxy (IP411LEFT: master PBX hq)
click on Add a host
The missing host (branch-b-dvl-ckl2.training.innovaphone.com) is suggested
add this host
finish the configuration with OK

This "trick" works because the plugin offers the PBX you are connected to as a new host in Add a host.

The reverse proxy configuration on your IP411LEFT is

fairly complete now.

Reverse Proxy - manual changes

What needs to be fixed manually

The plugin goes a long way towards configuring your reverse proxy in a master/slave scenario. However, there are still a few things missing.

If you compare the settings created so far with our complete reference for the reverse proxy, you will notice the differences.

settings created by the Reverse Proxy <i>Settings</i> App plugin

Global settings

The service ports are done OK

.

Service	TCP Port	TLS Port	Remark
H.323	1730	1310	All services accepted on standard port + 10
SIP	5070	5071
LDAP	399	646
HTTP	90	453

However, some of the recommended other global settings are missing:

Setting	Recommended Value	Remark	Created by PBXManager?
No IPv4	off	This flag disables IPv4 for the reverse proxy
No IPv6	off	This flag disables IPv6 for the reverse proxy
Log Forwarded Requests	off	No normal logs should be turned on unless you are debugging an issue
Log Rejected Requests	on	To see issues in the Logging App
Blacklist Expiration (min)	5	To avoid manual intervention if a client ends up in the blacklist for whatever reason
Suspicious Requests/min	20
Public NAT router address	172.100.0.1 / 172.200.0.1	must be set for incoming SIP requests to the public address of your NAT router, depending on the location (remember that 172.100.0.1/172.100.0.1 must be replaced by your internet routers IP address). You can leave this field empty if the RP also performs the NAT router function. If your NAT router offers different SIP ports (default 5060 and 5061), then you have to specify the port to be used. Since only one port can be specified, only either SIP/TCP or SIP/TLS will work. only if SIP is required (e.g. 3rd party devices). SIP trunks do not require this!

To fix the global settings, do the following changes:

tick the Log Rejected Requests for all service types used
set Blacklist Expiration (min) to 5
set Public NAT router address to the external IP address of your (simulated) internet router (the IP411RIGHT in this case)
You can find this IP address as IP address on the IP411RIGHT's IP4/ETH0/IP tab as well as on moodle's Devices page (IP411RIGHT external IP address (on your corporate network): x.x.x.x (this will be the external IP address of your router-hq))

Your global reverse proxy settings should

look like this then.