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 192.168.1.175, 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
jrecho last edited by
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
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
THANKS TO ALL WHO’VE CONTRIBUTED
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
IS THIS CORRECT GUYS ?
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?
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).
aftc50 last edited by
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 ?
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 enable SIP”, which makes no sense
donaldchapell last edited by
What provider are you using? We use Revos and have to use all kinds of VIP’s.
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!
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  (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
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” ?
What’s wrong with cli? (but he, I’m kind of a unix man )
drewdown last edited by
Security > ALG
Application Layer Gateway (ALG)
where is this stuff in the netscreen’s webUI ?
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