Hi,
I would like to provide external access to keevio from outside my firewall, what are the requirements to do this?
Depending on how much access you need, you will need to setup the following:
Add a public CA signed certificate to the PBX using a domain name that you can subsequently point at the appliance in external DNS. You can find the instructions for this here
Setup your firewall correctly, you will need TCP port 443 inbound on a static public IP address forwarding to port 443 on your appliance. The appliance also needs to be able to originate TCP and UDP “connections” outbound - in other words a statefull firewall rule needs to be added for outbound TCP connections, and to allow outbound UDP traffic and symmetrically allow inbound UDP reply packets from the destination address/port pair.
Setup external DNS to point the domain name you registered the certificate in step 1 above to point at the public IP from step 2.
Add keevio/HTTPS access to the filter in system/globals:
For many kinds of non-trivial remote keevio phone or video/audio/screensharing use you will need a TURN server on a public IP address to relay media streams for remote clients on firewalled networks.
rfc5766-turnserver, or coturn are perfectly good freely available TURN servers and you should install one of these on a suitably secured server on external connectivity using the instructions you can find at:
https://code.google.com/p/coturn/
An Amazon AWS server seems to work well for this but, if you are in Europe, you should set the instance up in a European Data Centre (e.g. Ireland/Frankfurt) rather than the default US Zone as the latter may give you excessive latency when talking UK to UK. If you are deploying on AWS in the EU-West (Ireland) Zone, then we have made a sample TURN server image available as a free AMI under id ami-e3ceec94.
Setting the following (non-default) values in turnserver.conf works for us:
external-ip=<your-ext-ip>
aux-server=<your-int-ip>:443
fingerprint
lt-cred-mech
realm= <your-turnserver-fqdn>
cert=/etc/ssl/certs/turn_server_cert.pem
pkey=/etc/ssl/private/turn_server_pkey.pem
no-multicast-peers
user=<your-username>:<your-pass>
Obviously you will need to replace <your-ext-ip>, <your-int-ip>, <your-turnserver-fqdn>, <your-username> and <your-pass> with the correct values for your environment, and install a suitable certificate for the turnserver domain name (which will obviously be different to the PBX appliance domain nane) in /etc/ssl… on the server.
If you do not have a key/certificate available, you can operate the TURN server in an insecure/unencrypted mode, but will need to modify the turnserver.conf configuration file appropriately. Most of the necessary documentation can be found in the config file itself. Clearly this is not a good idea for a production unit.
You should setup firewall rules something like the following up in front of your appliance:
inbound:
UDP 443 from anywhere
UDP 3478 from anywhere
UDP 5349 from anywhere
UDP 49152 - 65535 from anywhere
TCP 22 from <your-ip-range>
TCP 443 from anywhere
TCP 3478 from anywhere
TCP 5349 from anywhere
outbound:
TCP to anywhere
UDP to anywhere
Add the TURN server config to the appliance (using the turnserver info you setup above):
If you want to send external keevio invites as SMS messages then you will need a text sending account from an API provider. We currently support Nexmo. So you will need to sign up with them and enter your account details in the keevio messaging config:
Test external access, and then celebrate success (maybe on a beach with a 
whilst using keevio to stay in touch with your colleagues back at the office ).
Hi,
Do you have a more detailed definition of “non-trivial”? I assume I am hitting the issue you are describing. When a Keevio client, on the same subnet as the IPCortex device, tries to share screen with a remote Keevio client I can see the UDP connection is trying to go directly to the remote client’s local IP. Obviously the IP isn’t routable so is this where the TURN server comes into play to facilitate the media stream?
thanks
Tim
Ok read up on this a bit more and a STUN server will tell the client its public IP so that’s step one. Will keep reading!
Hi Tim,
That’s right, a working STUN server means the endpoints know their public IP and can tell the other end in ICE candidates to probe on this to try and build symmetric UDP firewall state. STUN servers are easy and low cost to provide so there are lots of free ones (e.g. google). If you have simple NAT that preserves source ports at both ends then just STUN can sometimes be sufficient to get by. To cover all cases like more complex NAT that generates random source ports and outright UDP blocking then you need a TURN server. These cost lots to provide as they have significant bandwidth implications, and can be abused so you won’t find any free ones.
Sorry I’m away at the moment so hard to keep up with the thread, but may be one of my colleagues will chime in if you have further questions
–
Rob.
Hi Rob,
It appears as though the ami-e3ceec94 is no longer available? Please can you provide a reason why this is no longer available?
Many Thanks