Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Mitel Teleworker - Make calls but no voice through Cisco PIX 2

Status
Not open for further replies.

Roadstone

Technical User
Apr 24, 2002
24
0
0
GB
Hi all,

We have a problem with the Mitel Telework setup at our offices, where we are able to dial connections from remote handsets (Mitel 5340's - switch is a 3300) and which ring through, but when awnsered we get no voice traffic either way. Before I continue, I should point out that I'm a data network engineer and have very limited experience with the telephone system. The Mitel setup is managed by an external company, who normally do not configure the MAS to run behind an external firewall.

Basically, the way we have it setup is as follows.

We have a perimited firewall (Cisco PIX 515) with a public IP address statically mapped through to the MAS in the DMZ (I have been told that it is actually a MSL running version 8.2.15.0, with a teleworker blade in it). The MAS is running in gateway mode, with it's external interface patched into the DMZ subnet. The internal interface of the MAS is on the same subnet as the Mitel 3300 switch.

We have the following access-lists configured on the PIX to allow traffic through to the MAS on the following ports.

=> TFTP UDP 69
=> Voice Media UDP 20000 - 20999 (complete range)
=> SSL Minet TCP 6801
=> Secure Minet TCP 6802
=> YA Support TCP 8001

Whilst I know I could exclude the PIX and assign the external interface of the MAS a public IP address, I would prefer not to bypass the perimiter firewall. At this point, I should also mention that if I patch a handset into the DMZ directly I can make calls with out any problems. That said, did see a post somewhere, were it was suggested that the MAS running in gateway mode, may not like the NAT that the PIX is performing. I'm not really sure as to how the data flows between the 3300, MAS and remote handset, or the order in which the connections are made through the firewall. As such debugging with tcpdump hasn't really giving me any indication as to where the call is failing.

Has anyone experienced similar problems, or able to recommend a potential fix?

Many thanks!

Rob
 
First big thing i notice is that you say it's in server - gateway (2 NIC) mode in the DMZ. This is NOT supported for that config.

To work properly behind a Pix and in DMZ it should be in Server only mode (1 NIC)

That nic should have an internal IP address from you DMZ range. Then the PIX does it's NAT thing from the external IP address to the internal IP address. certain ports if port forwarding or mapping.

The biggest thing to note behind a Pix is that you need to put the NAT statement on the inside and outside. The internal phones, when speaking to a remote phone, needs to communicate with the external address.
 
Hi Mitelmatt,

Thanks for that bit of information.

Rob
 
Hi Mitelmatt,

Can you copy the contents of the PIX document and post it directly into this thread.

Regards,

Rob
 
here you go but there is a diagram with examples on.

Let me know if you want an email:

The following are the Rules and NAT statements that are required for Mitel Teleworker to work through a Cisco PIX firewall, when the Teleworker is situated in a physical DMZ off the firewall as per the below diagram.
The operation of the Teleworker is that a phone on the internal network will access the outside IP address (public) of the Teleworker, in the case of the diagram above the IP address is 192.168.2.253 255.255.255.0. The call is then redirected to the Teleworker actual IP address in the DMZ, in this case 192.168.4.1. The Teleworker then directs it out to the remote phone sitting in the internet.

The remote phone sitting on the internet makes a connection to the Teleworkers public IP address. The connection is redirected to the Teleworker on the DMZ and then directed to the phone sitting on the internal network.

The Teleworker also communicates with the 3300 on the internal network for its call control and call setup, before the voice stream takes the path as described above.

It is therefore necessary to allow both the 3300 and internal phones to communicate with Teleworker and also to allow remote phones to communicate to the Teleworker via its public IP address. The firewall will also need NAT the traffic from both the DMZ to the internet and the DMZ to the internal network.

The following configuration example is based on the above network diagram and assumes that there is an implicit rule that allows all internal traffic out of the firewall to both the internet and the DMZ. Although the configuration below shows two named access lists. These names have been picked for this example. In most cases these access lists will already be in existence for other network access and applied to the relevant interfaces, so they just need appending with lists below.





Object-group service out_teleworker_to_networks_tcp_ports tcp
Port-object eq 22
Port-object eq 80
Port-object eq 3300
Port-object eq 2114
Port-object eq 2116
Port-object eq 35000
Port-object eq 37000
Port-object range 6800 6803
Port-object range 3998 3999
Port-object eq 6880
Object-group service out_teleworker_to_networks_udp_ports udp
Port-object eq 53
Port-object range 1024 65535
Port-object range 20000 23000
Object-group service in_internet_to_teleworker_tcp_ports tcp
Port-object eq 3300
Port-object eq 2114
Port-object eq 2116
Port-object eq 35000
Port-object eq 37000
Port-object eq 443
Port-object range 6801 6802
Port-object eq 3998
Port-object eq 6880
Object-group service in_internet_to_teleworker_udp_ports udp
Port-object range 20000 23000
!
Access-list outside_to_DMZ remark allows any outside device connection to teleworker
Access-list outside_to_DMZ extended permit tcp in_internet_to_teleworker_tcp_ports any host 192.168.2.253
Access-list outside_to_DMZ extended permit udp in_internet_to_teleworker_udp_ports any host 192.168.2.253
Access-list DMZ_to_networks remark allows teleworker to connect to any network device
Access-list DMZ_to_networks permit tcp out_teleworker_to_networks_tcp_ports host 192.168.4.1 any
Access-list DMZ_to_networks permit udp out_teleworker_to_networks_udp_ports host 192.168.4.1 any
!
Access-group outside_to_DMZ in interface outside_interface
Access-group DMZ_to_networks in interface DMZ_interface
!
Static (DMZ,outside) 192.168.2.253 192.168.4.1 netmask 255.255.255.0
Static (DMZ,inside) 192.168.2.253 192.168.4.1 netmask 255.255.255.0



In most cases the changes that will need to be made are to allow the specific ports in and out for the Teleworker and to make sure the NAT is correct. The NAT statements are what Cisco refer to as bidirectional NAT and without this there will be an issue with one-way voice.
 
MitelMatt,

Thanks a million. That was a huge help!! All is now working!!!

Regards,

Rob
 
Hi

I have a similar problem but I can only pass voice one way from the remote end. The internal phones cant pass voice back.

The server is in a DMZ running in server only mode natted to its own public IP address.

I am running PIX6.3.3

I was wondering if there is a full working example of a PIX configuration

Thanks in advance
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top