How do I verify ports for remote operations - in other words, check that I've forwarded the ports correctly? How do I protect my server against being hacked, or prevent an outside attacker from making unauthorized international phone calls?
Port forwarding and VoIP traffic
Hosted / remote customers
(On-site servers should skip down to the "Ports to forward" section)
Some enterprise-class firewalls block outbound traffic by default unless specifically allowed. Traffic should be allowed outbound (originating from deskphones/smartphones/computers) for the following ports.
ALLOW OUTBOUND: (this is unlikely to be restricted, but FYI)
80 & 8080 TCP - web admin panel, and certain HUD config functions. (http)
123 UDP - time for deskphones. (ntp)
443 TCP - HUD authentication. (https)
4000-4031 UDP - audio for HUDmobile. (pending)
5060 UDP - call setup and teardown for desk phones. (sip)
5060 TCP & UDP - call setup and teardown for HUDweb and HUDmobile softphones.
5222 TCP - HUD status and control.
5269 TCP - (optional) HUD external chat contacts such as Jabber and Google Chat.
10000-20000 UDP - RTP voice traffic. (audio travels over a randomly selected pair of ports in this range)
Premise-based servers
(Local servers only. Hosted customers should skip down to the "Disable SIP ALG" section)
All of the following ports MUST be forwarded to the internal IP address of your PBXtra in order to use IP Phones or HUD remotely! Unless, of course, you know that you don't use linked servers (skip port 4569 if so).
FORWARD INBOUND (only for on-site servers):
5060 UDP - SIP registration, used by remote phones and VoIP carriers.
(initiate, pick up, and end calls - call signalling and setup/teardown)5060 TCP & UDP - SIP for HUDweb and HUDmobile softphones.
10000-20000 UDP - RTP voice traffic.
(audio travels over a randomly selected pair of ports in this range)5222 TCP - HUD, used by remote HUD3 clients, HUDweb, and HUDMobile.
(5269 TCP is additionally used for external chat contacts and linked servers)4569 UDP - IAX2 registration and audio, for linked servers.
4000-4031 TCP & UDP - only if you have HUDMobile.
(audio travels over a randomly selected pair of ports in this range)443 TCP - Don't forward by default, but if HUDmobile is not connecting, try forwarding this.
8997 TCP - only if you have HUD Desktop screen sharing. (legacy)
For remote phones, remote HUD, and VoIP providers to work, these ports must be forwarded inbound to the PBX. Remote traffic hitting the public IP address of the router or firewall needs to be forwarded to the internal IP address of the PBX on the local area network.
Otherwise, remote phone traffic and VoIP providers will not be able to consistently reach or send calls to the PBX sitting behind your router or firewall.
NOTE: when performing port forwarding on your network, be sure to only allow trusted sources! Allowing untrusted sources can result in unsolicited registrants to your system. See Security Considerations below.
ALLOW OUTBOUND (on-site servers):
Some enterprise-class firewalls block outbound traffic by default unless specifically allowed. The PBX connects outbound on the following ports, in addition to the above.
Do not forward these ports*, but traffic should be allowed outbound (originating from the PBX) for:
21 TCP - FTP for phone config downloads (and server updates, if premise-based).
53 TCP/UDP - DNS, or Domain Name Service. Used for resolving hostnames such as "vpn1.fonality.com".
80 & 8080 TCP - HTTP. Required for the PBXtra to determine its public IP address, and download updates/patches. Also occasionally used for certain HUD config functions.
123 UDP - NTP, or Network Time Protocol. Used for time and date settings.
443 TCP - HTTPS. HUD clients also use this when first setting up their username.
8000 TCP - VPN tunnel. Required by the Web Admin Panel - the PBX establishes a couple of SSH VPN tunnels back to the Fonality datacenter on this port.
(some larger firewalls block outbound traffic on TCP port 8000 unless you add an exception.)
Tip: if your outbound firewall rules say "allow all", you shouldn't need to add specific allow rules.
*-With the exception of 443, which may be required for remote HUDmobile users - if you use HUDmobile.
Inbound ports that must not allow unsolicited inbound connections
(read the Security Considerations section below)
The following inbound ports should not be forwarded. Or at worst, they should be restricted to a very narrow range of IP addresses (use whitelists).
Don't forward: 21 FTP. (but don't block outbound access to remote FTP servers)
Don't forward: 22 SSH.
Don't forward: 69 TFTP.
Don't forward: 80 HTTP.
Don't expose phones to the Internet. At a minimum, inbound Internet access to TCP port 80 (HTTP) on the phone must be blocked.
Tip 1: Disable "SIP ALG" and other SIP-related helper services on the router/firewall
SIP helpers typically do more harm than good. In almost all cases, the following items should be disabled: "SIP ALG", "SIP Session Helper", "SIP Fixup", "SIP Debug", "SIP NAT Traversal" should be turned off.
Read this article for in-depth information. See the malformed-packet section below for detailed information on what this is and how to fix it.
Tip 2: Malformed SIP packets will cause problems.
FONcore expects to see uniform SIP packets. If the SIP packet has been modified in any way the packet may be discarded leading to dropped calls or the inability to connect a call. Usually this occurs when features on firewalls/NATs try to help SIP communication by altering SIP packets but it actually ends up interfering with FONcore built in method of traversing NATs. Common names for some of these features are "SIP Fixup", "SIP Debug", "SIP NAT Traversal" or "SIP ALG", but there are many other names as well.
Packets may also be processed by FONcall but the call can experience lost audio due to dropped packets or one-way audio if FONcall does not know where to send RTP packets because of a malformed source port.
Tip 3: UDP Timeouts
On certain firewalls/routers, it may be necessary to raise UDP timeouts to 90 seconds to ensure that phones don't briefly become unreachable (which can happen if the timeouts are at 30 seconds). These may be found under Firewall: Access Rules on some models, Advanced: Network, or Advanced: Conntrack/Netfilter on others, to name a few possible locations.
Security considerations
When opening or forwarding ports, there are some security considerations to keep in mind. These are guidelines - Fonality does not manage your network security - but these tips cover most common attack vectors.
Don't forward port 22 SSH.
If port 22 is forwarded to the PBX without IP restrictions, it will be subjected to thousands of brute-force username/password combination attacks per second. Fonality disables root password login on port 22 by default (unless someone has set a root password), but it should not be exposed in any case. If you need to log in on port 22, restrict it to only certain specific remote IP addresses, and use a strong password (many hacked servers thought they had a strong password).
Likewise, ports 21 (FTP), 69 (TFTP), and 80 (HTTP) should not be forwarded inbound.
Enable SIP brute force detection.
(requires PBX software version 2010.1.20+) We recommend enabling this on the Web Admin Panel under the Options: Settings tab. For example: after 20 incorrect attempts, block the IP address for 1 hour. This should at least cut down on people blocking themselves out because they typed their softphone password wrong, but most brute-force attacks will block themselves in under a second.
Whitelisting - only allow certain IPs to connect to port 5060 SIP.
If your router/firewall supports it, restrict what IP addresses can connect to SIP port 5060 (UDP).
Admittedly, this may not be as practical if you have remote users on dynamic IP addresses, but consider whitelisting their ISP. Then IP addresses from another ISP or country can't try to break in.Side note: How do I determine what IPs to whitelist?
----
If you wish to whitelist a VoIP provider, ping the host listed on the Options: voip page. This should allow you to continue receiving incoming calls on UDP port 5060. Be aware, there is no guarantee that the VoIP provider will *always* use that IP, unless they explicitly say so.
Avoid placing the PBX in a DMZ.
We do not recommend placing the PBX, a phone, or any server in a de-militarized zone, as a DMZ exposes all running services on it to potential attack. It's sometimes useful for troubleshooting phone registration issues, but should not be used in a production environment.
Don't forward ports you don't need.
A common sense rule - for example, if there's no VoIP carrier (purely T1/PRI or analog) and all of your phones are on-site (no remote sofphones), it's unnecessary to forward port 5060.
New types of attacks against network devices and software are constantly emerging. We believe in a proactive approach to security and by taking the measures suggested above, you can stay protected against future threats.
Other security tips
These aren't network tips, but are relevant to the topic of security and preventing unauthorized calls. Briefly:
Disable voicemail 'Callout'.
Under the Web Admin Panel: Users/Extensions: view users(or view extensions) tab. Click on an extension and look under the voicemail settings. Make sure that "Enable Callout" is set to no or disabled, unless you have a specific reason to enable it.
Disable international calling, unless needed.
Typically just the "9+011." dialplan (be careful not to affect 9+11 emergency). See editing dialplans.
Can I still contact Fonality Support for help?
Of course! However, Fonality's mission as a company is to make technology easy. Fonality believes that phone systems should not be complicated or take years of training and multiple certifications to administrate.
What is 'port forwarding'?
Imagine you have a business operating out of your own home. The law in most places states that you must have an entrance separate from the front door for customers visiting your home office. It helps to keep your personal and professional lives separate and protects your privacy. Within your network, port-forwarding accomplishes a very similar function: pass all traffic destined for the PBXtra directly without mixing in any other traffic. By explicitly defining a rule within your router that forwards all information on a certain port (or ports) to your PBXtra you are essentially creating that entirely separate entrance as in the home office example.
How do I forward a port?
It varies. Most SOHO routers have an administrative interface accessible from any computer on the Local Area Network. Please consult your manufacturer's documentation as Fonality does not provide support for customer-provided networking equipment.
For testing, if one is not remote oneself, one can have a remote coworker attempt to register a phone (be sure to add the "x" after the Server ID - see Remote Phone Directions), and if that's unsuccessful, after a few tries, ask Fonality Support if they can check.