[ale] Placing SIP Server in DMZ or use DNAT?

Phil Turmel philip at turmel.org
Fri May 24 08:32:38 EDT 2019

My self-managed Asterisk server is on my DMZ occupying one of my public 
IP's.  (It's really a VM in my office server, but is connected to the 
hypervisor's internal bridge for the vlan that carries DMZ traffic.)

But I'm moving it to a VPS in order to drop public IPs.

On 5/22/19 9:20 AM, Derek Atkins via Ale wrote:
> HI,
> I've got a network with the following configuration.  I am being routed
> IP range a.b.c.120/29.  The modem takes .126.  I've configured my
> firewall for .121.  I can add a switch between the modem and firewall to
> add additional machines there:
>                .126           .121
>     ISP -- <Modem> --<switch>-- <firewall> -- intranet
> I want to add a SIP server as .122.  I have two ways to do this.
> I could put it outside the firewall and just have it be natively on
> .122:
>                .126           .121
>     ISP -- <Modem> --<switch>-- <firewall> -- intranet
>                              \--<sip> (.122)
> Or I have it inside the intranet and configure the firewall to
> forward and rewrite packets via a set of (D)NAT rules:
>                .126   .121/.122
>     ISP -- <Modem> -- <firewall> -- intranet
>                                   \-- <sip>
> What do you all feel is the best approach?  I feel like the former is a
> simpler configuration, even though it requires one more piece of
> hardware.  On the other hand, the latter approach lets me have more
> visibility into the packets hitting the SIP server.
> I should add that I do have at least 2 phones/ATAs sitting in the
> intranet network that need to connect to the SIP server, but standard
> NAT should work for that.
> Currently the SIP server is sitting behind the firewall but living on a
> tunneled class-C network.  My IP phones are able to talk to it directly,
> and because it's got a public IP on the class-C it is reachable from
> devices outside the intranet.  Part of this project is to remove that
> extra level of latency caused by the tunnel, with the hope that removing
> that extra point of failure will improve my VOIP service.
> What do you all think?
> -derek

More information about the Ale mailing list