Re: [Shorewall-users] Talkswitch ip pbx and shorewall

[Simon H. <li...@th...>]

Michael Parker wrote:

>I  am  trying  to setup a Talkswitch telephone system with off site ip
>extensions. The sales talk is that by using ip you can have a 'remote'
>telephone  extension  that  can  be  configured  to answer the main
>main office telephone lines. Just like in the office
>were  you  can  have one extension on a pbx answer any of the incoming
>calls to the main numbers.
>
>I  have  been able to make it work sporadically but only for the initial
>call.  Then  the  ip  extension  phone  fails  to register with the
>Talkswitch system in the office and the extension goes down. I know it
>connects  because  you  can  reboot the extension an it is loaded with
>main office system configuration.
>
>This  is  my  first  foray  into  VOIP  and I cannot determine if the
>shorewall firewall may be the stumbling block.
>
>Their  support  gave  be the usual, open ports so and so and maybe use
>the  DMZ  blah  blah.  I tried everything from isolation in the DMZ to
>port forwarding. BTW we have our own 27 ip range.

Assuming this is "yet another SIP based PBX" ...

I'd put it on it's own external IP - it makes things a lot easier to 
deal with, SIP is really not nice with NAT. You then need to allow 
the ports through to the device according to the support docs you 
have. I'd guess port 5060 UDP & TCP for SIP, and whatever UDP ports 
it uses for the RTP streams.

For phones in the office, out a second NIC in the PBX on the internal 
network, and have the internal devices talk to it using the internal 
address - that eliminates NAT between the office phones and the PBX.

Now, for your external devices, this is where the fun starts ! While 
debugging, start off with a phone on one of your public IPs - and 
when you've got that working fully, move it to a 'foreign' network. 
Since this will almost certainly be behind NAt then you have a number 
of options :

1) Let the NAT gateway fixup the SIP packets - many have SIP helpers 
these days, though my experience is such that I turn them off.

2) Let the phone use STUN to discover it's network. An external STUN 
server can help the phone work out what the outside IP address is, 
and how the gateway is doing the NAT. In many cases this will be 
sufficient, but if you have a Zyxel gateway doing NAT - forget it, 
they scramble the port numbers in such a way that this will never 
work. When I've spoken to their technical people, they seem to have 
the attitude of "never mind if it breaks things, it's secure" !

3) If you have a fixed IP and control of the NAT gateway, most 
devices have the facility for you to tell them what their external IP 
is, and they'll use this in their SIP packets. Again, with most NAT 
gateways that preserve port numbers if possible, this works fine - if 
you have multiple devices behind a NAT gateway, then make sure they 
all use different SIP and RTP ports. This also doesn't work behind a 
Zyxel gateway.

4) Use a SIP proxy. I don't know of any, so if anyone know of a FOSS 
package I'd be keen to hear about it. I know Gradwell (who's services 
we resell at work) have hardware based proxies that deal with this. 
Essentially, the proxy gets the SIP and RTP packets from the device, 
ignores the address/ports in the SIP messages and uses the actual 
address/port the packets come from. It then talks to the SIP 
registrar in place of the end device. Since it ignores the 
address/port info from the client, this even works with a Zyxel 
gateway !

Note that Linux has included a SIP NAT helper module for some time, 
you may want to turn this off (prevent the module loading).

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.