Asterisk server static IP or behind NAT?

I'm designing my first Asterisk system, and I'm a bit stuck on where to put the server. I've got a bunch of Polycom {IP501,IP601} phones and a Linksys SRW224P Poe switch, and I'm building a box to run A@Home...

I have some public static IPs available, and I have NAT router(s) providing internet access to my LAN, so I can either give the PBX a static IP or put it on my LAN, but I can't figure out what's the 'right' thing to do.

Obviously I want to put the phones on the LAN, so I can move them around to any network jack, and they can supply LAN connectivity to connected computers. Therefore the phones will be behind my NAT router getting IP addresses in the 192.168.1.x subnet.

I figure I can either:

A) Put the PBX behind the NAT router. This puts the phones on the same subnet as the PBX, and adds some additional security by putting the PBX behind a (hardware) firewall. The downside is that there are ports to open in the firewall, and my impression is that connecting phones in other locations is more difficult and/or prone to problems.

B) Put the PBX out on the net with a static IP, but then don't the phones have to do the (STUN?) NAT Traversal thing to get to their PBX?

C) I suppose I could play some games with DMZ on a cheap router, but that feels like the worst of both worlds...

D) There's probably something I can do with VLANs on the switch, but that's a rathole, I can't find any good VLAN references, and I really don't want to try to learn too many things at once. 8*|

Anyway, I'd really appreciate some hints or general guidance from the experts here!

Thanks!

Reply to
William P.N. Smith
Loading thread data ...

The scenario B) is definitely the best. In Asterisk's sip.conf, in the sections for the phones behind the NAT, set "nat=yes"; do NOT enable STUN on the phones, because that would likely prevent communications among internal phones if canreinvite=yes in also set for them in sip.conf . In fact, canreinvite=no is the safest choice anyway, even though it may slightly increase the latency by forcing all the traffic to flow through Asterisk.

If you put Asterisk behind the NAT, you are going to have endless problems: port forwarding with SIP is not enough, as IP addresses are transmitted in ASCII inside the payload. Some modern routers have "SIP helper" modules able to modify them on the fly, similarly to what is done with FTP, but don't count of it. Dealing with NAT traversal is where IAX shines in comparison with SIP.

Even better would be to use as router the Linux box where Asterisk runs, and have Asterisk bind to 0.0.0.0. This way, neither internal nor external connections would be NATted...

For more details, see:

formatting link
(under "SIP and NAT - what is the problem, really?") and the scenarios described at
formatting link
.

Enzo

Reply to
Enzo Michelangeli

William:

I may be pointing out the obvious but.... Be sure to secure your Asterisk box if you put it on a static IP or in the DMZ. I have a test box in the DMZ and gets pounded all day and night by people trying to get into it.

Jonathan

Reply to
Jonathan Roberts

Yeah, also

formatting link
to say that my phones won't do NAT traversal very well, and (at least in the beginning) I'll be using the PBX with POTS lines, so maybe I'll put it inside the firewall to start with and see how it goes...

Thanks for the feedback, all!

Reply to
William P.N. Smith

formatting link
seems to say that my phones won't do NAT traversal very well, and (at

My personal feeling is that phones and asterisk should really be on real static IP's so that they can re-invite and have a faster direct talk-path. Putting your phones inside a NAT-ing firewall forces you to turn off re-invites and leaves asterisk in your talk-path. If the machine gets busy and asterisk gets delayed by a few 100ms, audio will "hiccup".

For security reasons you should run asterisk as some powerless user in a chroot jail. This is a bit fiddley to set up, but well worth it if some script kiddie finds an exploitable asterisk bug. And asterisk does have plenty of questionable code for kiddies to try to find some way to exploit. Look at the large number of system(...) calls. All of those are accidents waiting to happen.

-wolfgang

Reply to
Wolfgang S. Rupprecht

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.