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?
All of the following ports MUST be forwarded to the internal IP address of your trixbox Pro in order to use IP Phones or HUD remotely! Unless, of course, you know you don't use linked servers (skip port 4569 if so).
For remote phones, remote HUD, and VoIP providers to work, these ports must be forwarded. 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.
Some enterprise-class firewalls block outbound traffic by default unless specifically allowed. The PBX connects outbound on the following ports.
Do not forward these ports*, but traffic should be allowed outbound (originating from the PBX) for:
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.
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 expose phones to the Internet. At a minimum, Internet access to TCP port 80 (HTTP) on the phone must be blocked.
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.
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.
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.
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
trixbox Pro
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
trixbox Pro
you are essentially creating that entirely separate entrance as in the home office example.
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.
All of these things typically do more harm than good. Ask the customer to disable any of these settings within their router or firewall. 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.
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.
This test has been discontinued for the time being. We don't have an E.T.A. for its return at this time.
For historical reference / servers that still have the test page visible (although I don't guarantee that it will report correctly):
Until now, customers had only a single resource for information regarding remote phone and HUD issues: Fonality Support.
With the old Status --> diagnostics page, customers could automatically detect and view steps to resolve remote phone registration/audio issues and remote HUD issues.
That being said, 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.