Screen OS

Greetings! I'm currently scratching my head over a remote location that has been having issues with VOIP on a Route Based tunnel between an nsisg1000(local) and ssg5 (remote)

so as I am looking at the configurations, I notice that ALG SIP is enabled on one side but not the other. Without trial and error testing ... would having cause any problems? Is it safe to say it should be enabled on both sides or not?

I have read SIP ALG should be turned ON by default so I'm thinking there was a reason it was turned off in the first place. The nsisg1000 (local) just happens to be the one where SIP is disabled, so I am afraid to enable it just yet without botching other working remote locations.

Perhaps (and I haven't even done it before) a log would show an obvious need for it to be turned on/off?

I can compare to other locations, but I'm unsure if I will be comparing apples to apples considering this is the only location not using PBR. Thanks for any advise!

What are the security policies between the remote tunnel sip endpoints and that on the main site?

If they are allow all ports then you probabaly don't need the ALG.  What the ALG does is unblock the random ports needed to complete the call transport once the main call session is setup in the firewall.  If the firewall recognizes the SIP application setup it then allows instead of blocks the associated sip connections with this main session.

If the transport for these sip connections is the tunnel and it has no  block policy for these high sip ports then the ALG is not necessary.

thank you. 

from what you are telling me, SIP ALG seems to be more helpful than harmfull, honestly. There are no security polcies at all so... I guess removing SIP ALG at this time may be just for asthetic reasons only.

I was afraid of this answer, however, since this was an effort to thwart a problem with VOIP between the two locations. (just plan wierd issues) Maybe it needs to be enabled in this case, if I am wrong about security policies. 

There is always the possibility of some unintended consequence of having an ALG on.  So it is not impossbile.

Check the traffic logs when you have the issue.  If the sessions are flagged in the description as SIP indicating they are hitting the ALG then it could be an issue.

Hello ,

1. Usually SIP ALG is triggered only when the traffic on the firewall is using  port 5060. If the VOIP traffic is not on this port, ALG on the firewall might not be triggerred.

2. You can check if ALG on the firewall for SIP is used or not by using the command " get alg sip counters " or " get alg sip call" . On this basis, you can decide if the ALG is used in the device or not.

3. On teh device where the ALG is enabled, make sure that the policy for traffic does not have application selected as IGNORE. This setting usually disables the ALG feature for that traffic using that particular policy.

4. Also Policy based routing ( PBR ) and SIP ALG functionality are not related.

Regards

Vatsa

thank you for the help!

On a whim I disabled SIP ALG on the remote side (so now on both sides its disabled) and that seemed to clear things up a bit (as far as connections are conserned). Still have VOIP quality issues, but that's an entirely different problem I believe I can deal with.

I noticed that on the local side where SIP ALG was disabled there was no output for the commands "get alg sip counters" and "get alg sip call". I assume this is expected. The remote (that now has SIP ALG off) has high numbers but they are not incrementing.

Update: So I found a similar issue with ALG SQL which was causing grief with the remote site trying to do SQL queries as well. Disabling it on the remote end made me a hero in seconds.