VoIP traffic going out ok but netscreen blocking incoming !

  • We are configuring Juniper Netscreen 5GT to allow VoIP traffic via asterisk PBX

    The Asterisk PBX has local address, which I associated with its external IP, a.b.c.d by way of a MIP, on the Juniper.

    Then I went to Policies and created an “untrust to trust” Policy, source address = Any (from the address book), dest address = the MIP I had defined earlier, Service=ANY (just to get started, will home in on VoIP services later)

    Using an Xlite phone on the desktop, it registers ok with the PBX, and a call can be made using the VoIP trunk.
    However, while the external phone I called can hear me, I can’t hear anything from it.
    Also the same when I use an analogue extension plugged into the PBX directly, to dial out over the SIP gateway.

    what am I missing.

    NB, the guy who’s loaned me this PBX had VoIP working perfectly to this selfsame SIP gateway a few weeks ago, on his home network. So it shouldn’t be a problem with the Asterisk PBX or Voip gateway - more likely to be the Juniper config

  • Hi guys I am having a similar but more complicated issue.

    I have Voip server MIP in DMZ sending an inbound call received from interface trust going to a server on the untrust. Traffic gets and audio works fine between Trust and DMZ but when I make a call coming from Trust going to DMZ and then forwarded via trunk sip to unstrust with ALG enabled, I have no sound as soon as I disable ALG it works fine.  I spent hours trying different things but can not get it to work.

    I really like the concept of ALG and would love to keep in enabled to avoid opening 13K ports in UDP. But for the life of me I can’t get it to allow sound to pass thru.

    Can anyone help please

  • Global Moderator

    Congrats! Good for you!

  • Hi Screenie, No I didn’t enable incoming NAT ion the DIP

    but its ok as we now have 2way audio !!

    I’ve setup an incoming policy for VOIP (the predefined service group on the juniper, which includes the predefined service SIP), which looks after the SIP

    and then I’ve left the SIP ALG enabled, which looks after opening ports for the the RTP/RTCP traffic (rather than opening a load of ports permanently)

    Also, my Asterisk guy had a tinker around with its config and tidied a few things up which may have contributed also…

    end result = success!
    now have VoIP trunk capability on all 4 of our IP extensions


  • Global Moderator

    You’re correct Zorba! Alg’s are for opening specific incomming ports based upon session info found in a related outgoing session. The situation in wich disabling it resolved a problem for me was over a VPN not inbound. So just a hunch, did you enable allow incomming nat on the dip settings of outbound interface? You shouldn’t need it because you are using a MIP, but maybe it is worth a try!

  • Also, another reason against NOT using the ALG is that RTP and RTCP are not defined as predefined services in the Netscreen, so they have to be set up as custom services whcih is extra hassle

    PLUS no-one knows what port range to specify to get it 100% right - so you have to just cross your fingers, pick a range, and hope that none ever initiates a session on a port outside your range

    THIRD drawback, already stated, is that thousands of ports need to be opened…

  • Phew, after reading the pertinent parts of the ScreenOs “Concepts and Examples” pdf (http://www.juniper.net/techpubs/software/screenos/screenos6.1.0/ce_all.pdf), namely Volume 6 (VoIP) Chapter 2 (SIP), AND frequent recourse to Wikipedia etc, I now think I have a grasp of how all this works…

    We need to have some sort of NAT, so create a policy to allow SIP traffic over our MIP.

    BUT, SIP is only half the story - it only sets up the calls, and controls them - we need to creates RTP/RTCP sessions to actually stream the audio back and forth.

    To stop RTP/RTCP getting blocked by the firewall, we have 2x choices:
    a) create a custom service for the range of ports, which Wiki says is 16384-32767, and some other sources say is 10000-20000, or
    b) enable the SIP ALG, and let it manage the dynamic opening of short term ports (pinholes) needed for RTP/RTCP


    If it is, I have to look at the tradeoff
    Option (a) seems dangerous - keeping 10-16k ports open for just one application seems a bit risky/reckless. Then again, if as has been suggested, option b) is problematic, (a) might be the only option.

    I think I’ll try (a) first and see if I can get it working by relying on the SIP ALG, as it seems more elegant.

    Any comments, compadres?

  • donaldchapell:

    We are using a SIP gateway called Telappliant (at voiptalk.org), based in the UK, as we are there.

    I got away with just creating a MIP (to do the NAT).

  • i have the same problem with my asterisk server and i opened Jtac case . they told me you have to disable the sip alg . i did it a everything is working fine. i have question why do they enable it by default ? and what is the benefit of it ?

  • thanks screenie,


    unset alg sip enable

    just means “switch off the SIP ALG”, i.e. same thing as unchecking the SIP option under ALG in the GUI.

    that last “enable” is what threw me, at first I thought there were 2x parts to the command, ie.

    unset alg

    …and then…

    sip enable

    = “unset ALG and then enable SIP”, which makes no sense 🙂

  • What provider are you using?  We use Revos and have to use all kinds of VIP’s.

  • Global Moderator

    Hi a short comment on strange syntax in ScreenOS:

    General rule: to set something you use set …  to unset you use unset. No supprise I think.

    now to enable something you use:

    set … enable or abriviated set … ena

    consequent but ugly to disable:

    unset … enable (ore ena)

    So to disable the sip alg

    unset alg sip enable. Can’t help it!

  • found this:

    On 7/17/06, Mark Steph < mark.steph@xxxxxxxxxxxx> wrote:
    The alg stuff is where the netscreen tries to be “smart” and do more
    screening based on stuff deeper in the protocols.

    For example, there is an alg for msrpc that tries to figure out what
    ports to open for microsoft RPC calls…. and this consistantly makes
    those protocols break.  Unsetting msrpc makes them work.

    I dont deal much with sip or h323, but I know the R&D guys here at
    Ericsson always request alg to be off on firewalls I manage.  It is
    worth a try.  If it doesnt work, you can always put it back.

  • Never heard of ALG (“Application Layer Gateway” or “application-level gateway”) till yesterday, and trying to get my head around it…

    Wikipedia starts its definition thus:
    “In the context of computer networking, an application-level gateway [1] (also known as ALG or application layer gateway) consists of a security component that augments a firewall or NAT employed in a computer network….”

    Any better definitions/explanations/examples of ALG out there ?

    So it seems to pick up traffic for a specific application (eg SIP) and do a sort of clever NAT, without the need for setting up static NAT tables (eg Juniper policies). Correct?

    So I’m guessing we use either NAT or ALG, but not both together - as from your comments Screenie, they don’t interoperate well

    The only thing that confuses me is the “enable” at the end of the CLI command. is it just an anomalie ?

  • Here is the layout.
    (I am not tecchie, and don’t even know how to access CLI…)

    Application Layer Gateway 
      Microsoft RPC 
      Sun RPC 

  • I have a Juniper-NS5GT-ADSL

    Configuration > Advanced > ALG > Configure

    it gives a list of protocols (eg SIP) with a check box beside each one
    the are all checked

    a) is this the right place?
    b) do I need to uncheck “SIP” ?

    many thanks

  • Global Moderator

    What’s wrong with cli? (but he, I’m kind of a unix man  😄 )

  • Security > ALG

  • screenie:

    Application Layer Gateway (ALG)
    where is this stuff in the netscreen’s webUI ?

  • drewdown:

    We already have a policy from trust to untrust, to pretty much let anything thru’ (see below)

    From Trust To Untrust, total policy: 1
    ID Source Destination Service Action Options Configure Enable Move
    1 Any Any ANY  Edit Clone Remove

    I think this is what’s allowing audio traffic out ok
    the problem is with the opposite direction