12-19-2008 08:24 AM
Hi Gavrillo, now I see what you mean: indeed when using STUN with SIP you don't need the SIP ALG. STUN is invented to overcome PAT firewalls, just like the SIP ALG is. You can either use one or the other, not both. In some SIP clients you can choose to enable STUN. However when the SIP ALG is enabled, you can't use STUN, as the ALG will have a problem with some non-standard SIP messages that are the result from using STUN.
So Gavrillo is right in that you don't have to use the SIP ALG.
However assuming that the client phones use proper pure standard SIP, you will need the ALG in this scenario.
The reason is that when using PAT, the SIP ALG is needed to open a pinhole to let the incoming media stream in.
Without this pinhole being opened, the incoming packet for a new session (incoming call INVITE message) will be dropped because it does not match an existing session. Then the firewall has no way of knowing to which SIP client IP address on the trust side to forward the incoming packet to.
This is explained in the 6.2 C&E Guide page 33 and further (Incoming SIP Call Support Using the SIP Registrar):
"The security device monitors outgoing REGISTER messages, performs NAT on these
addresses, and stores the information in an Incoming DIP table. Then, when an
INVITE message is received from outside the network, the security device uses the
Incoming DIP table to identify which internal host to route the INVITE message to."
For this (reading the outgoing REGISTER messages and creating the Incoming DIP table) you need the SIP ALG.
Sorry for the long message. Hope this sheds a bit more light :-)
12-22-2008 01:36 AM
Hello Ghostrider (and gents),
As you said before, I don't want to start a debat here too but I have to say that we have been able to make and receive SIP calls from the IP world and the PSTN world without activating the SIP ALG. The only thing we had to implement is policies in order to let the SIP flow out and back in through the firewall.
We've tried the SIP ALG feature shortly and we noticed that the SIP message body was modified, which was expected according to the manual. But we we're not so pleased with that because we don't want the SIP messages to be modified so we disabled it.
As a conclusion, I just wanted to say that I agreed with Gravillo when he says that SIP can work whitout the SIP ALG, the dynamic NAT combined with carefully implemented policies should do the trick.
Anyway, thank you for your time and your expertise, you've been very helpful guys.
Cheers and regards.
12-22-2008 02:34 AM
I have one last question regarding this matter. What about the "set dip sticky" option ?
In KB9093, it's not refered to it but it's shown in KB6374 and in the manual. I have read about it also in the ScreenOS 6.2 IPv4_CLI.
Knowing that I haven't set any IP adresses in the DIP pool (meaning that all my clients will be NATed with the same public IP adress on the Untrust Zone), do I need to activate this option ?
Please take in consideration that some clients will be using Hard phones (mostly) and others softphones.
12-22-2008 02:42 AM
"set dip sticky" makes sure that a client will always be mapped to the same IP address in the DIP pool. If your DIP pool only contains one IP address, like in your case, if I'm correct, the interface IP, then you don't need to set it.
When using a DIP pool with multiple IP addresses, the "sticky dip" setting will be important if you have an application (without ALG support) that uses multiple connections. Then these connections need to be mapped to the same public IP address, so that the server on the internet will see those connections coming from the same IP address.