IP Phone Offsite

[Camoron]

I am new to setting up IP phones offsite. I know you need to enter the ICP IP and the TFTP server IP (these are the phone system generally), but I've never set one up offsite before except when connecting to a phone system with a public IP. I was just wondering if there was an easy way to do this, as I am currently thinking we will need to either 1. Request an additional Public IP from the ISP for the client and use it for the phone system, or 2. Request an additional Public IP from the ISP for the client and use it for one-to-one NAT with the phone system on a private IP. I believe another option would be to use a VPN, but the client doesn't plan on setting one up as far as I know (they have one worker who will be in the UK using their IP phone offsite without a VPN). Any tips?

Thanks.

[IPInstaller]

Hi.

We always use a NAT public IP address and open the required ports on the corporate firewall, or use an MBG preferably. The remote/client public IP doesn't have any bearing, as long as the corporate firewall allows the connection.

As long as you open the below ports (for 53xx IP phones) you should be ok.

68, 69 and 20001 (UDP)
6800–6802 (TCP)
3998 and 3999 (TCP)
5004–5007 (UDP)
50098–50508 (UDP)
6004–6261 (UDP)
6604–7039 (UDP)

Hope it works.
IPI.

[Kingdomfire]

Another option is a P2P VPN.

MBG and VPN's offer security that a simple NAT translation won't. Maybe worth looking into!

If you're connecting a phone at someone's house then the VPN may not be an option because of poor home routers. May also be an issue with the ports though.

MBG and teleworker works a treat. We have many sites connecting back to their head office PBX through a single MBG!

[Camoron]

Thanks for the replies. I mentioned a Border Gateway to my boss and was wondering how much they cost so we can determine if it's something our client might be willing to pay for, bearing in mind that, for now, they only have a single offsite IP phone.

[acejavelin]

I am new to setting up IP phones offsite. I know you need to enter the ICP IP and the TFTP server IP (these are the phone system generally), but I've never set one up offsite before except when connecting to a phone system with a public IP. I was just wondering if there was an easy way to do this, as I am currently thinking we will need to either 1. Request an additional Public IP from the ISP for the client and use it for the phone system, or 2. Request an additional Public IP from the ISP for the client and use it for one-to-one NAT with the phone system on a private IP. I believe another option would be to use a VPN, but the client doesn't plan on setting one up as far as I know (they have one worker who will be in the UK using their IP phone offsite without a VPN). Any tips?

Thanks.

BTW... independently setting ICP and TFTP is redundant, just set the Teleworker mode and it handles everything on the phone end for you. Press and hold 7 when powering on, follow menu, and enter the public IP address that is port forwarded to the Mitel. Otherwise the instructions above are correct.

BTW, this works fine for small implementations, the security implications are minimal. MBG isn't necessary unless you are going to deploy quite a few sets or have other reasons for doing it.

[Camoron]

Thanks for the tip about Teleworker. So I need another, separate Public IP for the phone system to use, right? They can't use the one the company as a whole uses for NAT with all their networked devices, correct? Do I need to request this from the ISP directly?

[jburdick]

I send this email out to the it guy on new setups... hope this helps....

Please have your firewall administrator forward the following ports on one of your static public IP addresses to the same ports of the Mitel phone system private IP X.X.X.X  to enable remote Administration & Diagnostics, remote User Web Portal access, as well as Remote Phone connectivity from the Internet.

I have crossed-out ports that are not needed for this particular implementation and thus do not need to be forwarded in the firewall. All others are definitely needed.   


Port Forwarding for Remote User Web Portal Access as well as Admin & Diagnostics

22                           TCP                        (SSH) Diagnostics Management Utility
443                         TCP                        (HTTPS) Admin/Diagnostic & End User Web Portal
44000                    TCP                        System Admin & Diagnostics Program Interface

•   If there are conflicts in the firewall with these ports, please use alternative ports such as 9922 and 9443 on the outside interface and point them to ports 22 and 443 of the phone system internal IP.

•   For security, please lock down ports 22 and 44000 to only allow traffic from our public IP at _____:  xxx.xxx.xxx.xxx
o   However, please allow traffic from any public IP to 443 so users can login to the User Web Portal from any external IP address (if the customer authorized User Web Portal access for end users outside the office).

Port Forwarding for Remote Phone Functionality

67-68                        UDP             DHCP Information (optional if set statically)
69                              UDP            TFTP for phone firmware
3998-3999               TCP            SAC protocol (phone apps & button programming on 53xx phones)
5004-5007               UDP                RTP for 86XX phones
5566-5567               TCP/UDP      Call Control for ITP phones (86xx) outside the firewall.
6004-7039               UDP               RTP & RTCP for VoIP outside the firewall.
6800-6802               TCP                 MiNet Protocol for basic call control of Mitel IP phones.
20001         UDP                TFTP for phone firmware
50098-50508      UDP                 RTP for 52XX/53XX phones
                               
•   Please allow traffic from any public IPs for these ports so remote phones can connect from any external IP address.

Please have your firewall administrator contact me with any questions.

Thank you,

[Matt_Womack]

As a tech with a network background, please do NOT open port 22 to the outside world forwarded or not.

We usually close that, and only SSH into the device locally because it's a huge security breech. If you have to SSH into the device you probably already need to be present at the site.

That's my $0.02

[Camoron]

Wasn't going to... we don't plan to allow any system administration offsite in this manner, as far as I know. Thanks for the info!