Teleworker Audio Issues

[hornetswfc]

I have a teleworker configured as server only mode with one way/no way audio. The 3300 and IP phones send their udp packets to the external ip address which is blocked. I have tried to edit the 15udp_icpside_address and enter the internal address but they still reply to the external address.

Does anyone know how to change the teleworker so it makes the 3300 and Ip phones send responses back to the internal address?

 

[Mitelmatt]

No it doesn't work like that i'm afraid. You nned to put an Ooutside Nat statement in your router to push all traffic to the external address. Works fine. So on the router interface to the DMZ you should have:

IP Nat inside source static xxx.xxx.xxx.xxx (internal) xxx.xxx.xxx.xxx (external
and
Ip Nat Outside source static xxx.xxx.xxx.xxx (internal) xxx.xxx.xxx.xxx (external)

Also, on the teleworker server make sure you have all the networks in Networks Tab

If all that doesn't work, could be a firewall issue?

That is the course of 80% of the time.

The reason it's done like that is so people can take their teleworker phone from home to work and vice versa without needing top re-prog

 

[kwbMitel]

You haven't mentioned a DMZ.

In server only mode the only supported config is within a DMZ. The DMZ must be a physical port on the firewall.

Does your config meet these specs?

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[hornetswfc]

The Teleworker server is installed in the DMZ, the issue I have is the internal network cannot connect to the external IP address of the teleworker. Therefore when the teleworker server talks to the 3300 or IP phone on the LAN you can see the phone and 3300 sending responses to the external address. As this cannot be connected to one way/no audio happens.
I need the 3300 and phones to send responses to the internal address and not external. I have created an override file with a new setting for udp_icpside_address and can see this in the tug.ini file but it stills fails. I want to change the teleworker so it requests responses back to its internal address.

 

[Mitelmatt]

Did you not read my post? This is not how it works i'm afraid.

 

[hornetswfc]

Mitelmatt

Sorry I did read your post, i have been advised that the Teleworker will not work with a cisco pix firewall.

Does anyone know of a work around.

 

[Mitelpassion]

one way or no way audio are usually to do with the nat'ng capability of the firewall, if the problem is firewall related.

most firewalls can't keep track of the random udp ports that are used for the voice packets.

Does your set register but you only have audio issues? I would suggest an problem with the firewall then.

Also like KWB said it's only supported in server only mode if you have a physical DMZ configured, in other words a third interface on your firewall. To reiterate what Mitelmatt saying: The phone and controller WILL talk to the external addy (as per documentation). Not really sure why, it just works that way. good luck

 

[Mitelmatt]

Cisco PIX Firewall IS supported, have it working fine numerous times. Have a doc from Mitel (which i've amended slightly). Have you got an address i can send it too?

 

[hornetswfc]

All

I have managed to resolve the issue by editing the udp_setside_address and udp_icpside_address in the /etc/tug/tug.ini file. Then set the teleworker into lan mode now the 3300 and ip phones send response to the internal address and no audio issues.

Thank you

For your help.

 

[nappyshock]

The reason for the one way audio is your UDP traffic is getting blocked.

The PIX will support a 3300 in server mode,It is a bit involved to setup if you have no previous experience. The pix works by having a security levels on the interfaces and by default only permits traffic from a higher security level to lower, the inside (LAN) is 100 , the outside (internet) is 0 and the DMZ is 50, so the outside can't get to the DMZ or inside without permission and the DMZ can't get to the inside without permission. So with your server on the DMZ it is not going to be able to initiate any communication with the ICP on the inside without you putting a access-list on the inside interface permitting it.

Basically if the PIX is doing the Natting you need...

static (inside,DMZ) x.x.x.x y.y.y.y netmask 255.255.255.255

the x.x.x.x = the IP address of the server on the DMZ
the y.y.y.y = the IP address of the dedicated Public IP address on the outside interface you are going allocate for the teleworker.

On the access-list that should have been setup inbound on the PIX's outside interface (i'll call it NAME) you need...

access-list NAME extended permit tcp any host y.y.y.y eq 6800
access-list NAME extended permit tcp any host y.y.y.y eq 6801
access-list NAME extended permit udp any host y.y.y.y gt 1999


On an access-list setup outbound on the inside interface (i'll call it NAME2) you need...

access-list NAME2 extended permit tcp host x.x.x.x host z.z.z.z eq 6800
access-list NAME2 extended permit tcp host x.x.x.x host z.z.z.z eq 6801
access-list NAME2 extended permit tcp host x.x.x.x host z.z.z.z eq 6802
access-list NAME2 extended permit udp host x.x.x.x host z.z.z.z gt 1023

the z.z.z.z = the IP address of the ICP on the LAN

As you can see it can get a bit involved, if you post the PIX's config i can give you more accurate advice.

 

[hornetswfc]

Mitelmatt

Can you please send the document to wfchornets@googlemail.com for future reference.

nappyshock

Thank you for you help.

 

[xi2008]

Mitelmatt;

I would really appreciate it if you could send this document to me aswell?

publicmail@infinitycm.co.uk

Thanks a lot

 

[slapin]

The only question is why you are trying to use the TW solution in dual interface configuration with designation of internal and external sides? If you are trying to keep everything in DMZ behind NAT hoping that it will protect you against any sort of threats it is not true.
1. For common protocols like http, ftp and others some firewalls can inspect traffic and apply some actions in event of violations. Mitel has proprietary protocol which cannot be verified against standards
2. If you are trying to have protection against DOS attacks to the OS, then TW server has iptables based firewal which is very strict on public side.
3. It doesn't matter what kind of NAT/Firwall you put in front of the application if it has to communicate with hosts in the public Internet you introduce risks which are not really mitigated by this massive and complex firewalls.
4. What is going to happen if you manualy tweak the product and then upgrade to a new version which may not support those tweaks and you will have to re-do the whole thing not even counting downtime of the system.
5. Sorry for not answering to direct question, but I always have to ask "why?". Tell us what you are trying to accomplish and what are your requirements as an end user and someone here will give you good advise.

 

[boycey9]

MitelMatt, I used to have that doc too but for the life of me cant find it now I need it, Could you mail it to boycey9@hotmail.com please