I'm having a problem getting Mitel's Border Gateway (formerly known as Teleworker) working properly. For those not in the know... Mitel is a large VOIP phone system company and they have various addons, including a server which would typically sit in your DMZ and allow remote workers to have a handset in their home / remote location as if they were in the office. The server has an private (RFC1918 IP Address) and the firewall NATs a public IP to the server, just as many other setups would work.
The phone in the remote location is configured to communicate with the public IP of the Teleworker server which in turn translates to the Teleworker server which then makes contact with the internal VOIP devices as necessary. No special programming is required on the remote users router. It's designed (sadly!) so that all the hard work is done at the company firewall...
The problem I have is that when the remote user calls an internal number, there is two way audio. When the intenal extension calls the remote user, there is one way audio - the remote person can't hear the audio.
As much as I'd like to blame Mitel and the telephony engineers, when we had it working behind a Check Point (sorry for swearing) firewall, it was fine. Behind the Palo, I'm getting the above mentioned grief.
Does anyone have any experience with getting this working!
Hi UKRB...Is Mitel using SIP over TCP/5060 and/or UDP/5060? You can filter in the traffic log to see what traffic is going to your Mitel server. You can try doing an app-override for UDP/5060 with dest=Mitel server and also for src=Mitel server to handle bi-directional traffic. You will end up with 2 app-override rules. Do the same for TCP/5060 if that does not help.
See how to create an app-verride here: https://live.paloaltonetworks.com/docs/DOC-1071
I'm late to the party here, but I use MBG behind a PA-2020. TBH, I just NAT and allow all traffic to that public IP. It's a Border Gateway for a reason -- it's made to handle the Internet directly. I did intend, at some point, to go back through the config and do some packet captures to lock it down to only the necessary ports, but I haven't done that yet.
FYI, my config is thus:
MBG outside has a DMZ internal IP, NATted to a public IP by the PAN. This public IP is placed in the MBG config's outside IP override field. (Have you done this?)
MBG inside is on a different subnet, with routed access to the VoIP PBX.
I haven't looked to see whether anything the Mitel system does is even remotely like standard SIP. I know it uses "MiNet" as its protocol. Haven't gone any deeper than that. Yet.
Thanks for the replies. I haven't got as far as creating and app-overide as currently I can't get the solutionworking when there is nothing blocked whatsoever!
My current setup has a single NIC and single IP configured on the Mitel server and that then NATs out. The problem I have is that the traffic from the internal devices is set to communicate with the Mitel server on it's public IP. So the traffic almost goes in and out again.
Does anyone know a good way of troubleshooting NATing so I can see when a packet goes through the firewall, how it was manipulated? A log for the NAT policy is essentially what I'm after. When the traffic goes to the external IP of the Mitel server I don't know if it gets NATed out as other traffic would and then back in with the source then as the firewall. What perhaps would be good is if I could make it so when traffic from the inside is bound for an external IP it doens't change the source address. Currently I can see that the source can be changed to X, but I want it unchanged if that makes sense.
I know this is a very old thread but we have just implemented Palo Alto to replace a Juniper and are having what appears to be exactly the same issue as you with Mitel Teleworker.
Worked absolutely fine with the Juniper but getting one way voice with the Palo Alto when initiating the call from an internal Mitel set or dialling in from the PSTN. We rely on Teleworker to such an extent that we have had to roll back to the Juniper.
Did you manage to find a solution?
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!