SIP Problem with NAT

Dear Bros! Anyone help me pls... Another trouble, when upgrade to latest build V3.00, MR6, build 662,..after SIP call established, i only can talk within 18-20 seconds...then the session will be iterrupted...hixhix... Big tks to All! Brgds

a general rule in order to make a Fortigate " SIP Aware" is like: #1 create a FW Policy (direct, NATed or VIPed) with SIP allowed (udp/5060 normally) #2 create a Protection-profile with " SIP" ticked on under the VoIP Section #3 apply this profile to the policy created in #1 This enables the SIP-ALG that will NAT (SIP-Header NAT) and open the RTP ports dynamically that are exchanged within SIP/SDP. Don' t underestimate the complexitiy of SIP and its friend RTP! -R.

We just spent the better part of 2 days fighting with something similar. We just deployed an Asterisk based PBX (Fonality...also known as Trixbox). We have a Fortigate 60B w/ the latest firmware. Phones were registering just fine, outbound calls were making it to our SIP trunk provider, but we were getting one-way audio. Obviously a problem with the RTP stream coming back. But we put the PBX in the DMZ, and left it wide open. So, finally, here' s what we did: 1. Removed the SIP session helper entry through the CLI 2. Disabled session helper 3. Made sure NOT to enable any protection profiles that have " SIP" checked I know the opposite is true for some other IP PBX systems based on comments I' ve seen in the forums, but this is what worked for us! By the way, here' s a quick run down of the config we used: DMZ-->WAN1 All allowed; NAT on; virtual IP mapping the public address to the IP of the PBX server WAN1-->DMZ SIP (5060), UDP6600, and UDP10000-50000 Allowed

Same problems here, except that we didn' t manage to solve it. We even try to make things more simplier. We have public IP on WAN1 interface and we have public IP C class on INTERNAL interface on FG-100A and phone is able to register but no audio is passing trough FG-100A. All protection profiles are disabled only policy which allows traffic from wan1 to internal for all traffic exist and policy which allows all traffic from INTERNAL to WAN1 exist. And still SIP does not work.. I would say again... We put some SSG temporarly in place of that FG-100 to enable VoIP to work.

if i re-read my earlier posting - it doesn' t say " disable protection profile" . In order to get VoIP (SIP/RTP) to work you normally need a Protection profile with " SIP" ticked on. For all those that may need a recap: VoIP (SIP/RTP) consist of the signalling channel which is " SIP" (usually tcp/udp 5060) and the " packetized speech" -> RTP. SIP only maintains the call setup etc. and it tells the peers on which RTP ports the " voice" is being sent and received. Having that said you need " something" intelligent that parses the SIP communication, takes the appropriate information out and opens the RTP ports dynamically (to maintain security). This " something intelligent" is the protection profile, attached to a " SIP / PASS" policy that listens to SIP and magically opens RTP. #diag debug enable #diag debug application im 255 will show you all the freaking details during a call setup and it will also show you the dynamically opened (pinholed) RTP ports (search for pinhole). Needless to say that this outgoing SIP-policy normally also needs NAt to be ticked on. ALSO - DO NOT USE stuff like STUN enabled on your PBX/Phone. Google is your friend to help understand what STUN is for and why it should not be used wih Firewalls that DO understand like Fortigate does. According to your decription (Not use either Protection profile or the (old) session helper) it cannot work. And it will not. Either use the (Old) session-helper OR (recommended) use the protection profile with SIP enabled. You only need ext(VIP)->>dmz(voip-srv) proto(sip) allow and have a " SIP enabled" protection profile to that policy !! Why do you use NAT ???? your PBX than will see the " DMZ" IP as the " sender IP" - sounds useless. A VIP does DST-NAT, SRC-NAT won' t be needed i guess. -R.

red.adir, Thank You very much for Your deep explanation of the way how sip is functioning and diag debug syntax. Altough I have few more questions. In Your post You mentioned " old session helper" , do You refer here to CLI command config system setings set sip-helper disable or to something else. In my current setup I' m using sip session helper without any protection profiles. I was not aware of the fact that sip helper is now deprecated and that only sip checkbox in protection profile is relevant. I was trying to simplify the things as much as possible and that was the reason why I disabled all protection profiles and put public IP' s on all phones to avoid all possible issues with NAT. In my setup I also don' t have local SIP server, I' m using one of the SIP service providers and all my phones connect to provider PBX. Do You suggest to me that I should put all phones behind NAT and put VIP for the provider sip server ? Can you please explain little bit more this sentence " A VIP does DST-NAT, SRC-NAT won' t be needed i guess. "

config system setings set sip-helper disable

That' s the " old" " kernel based session helper" ; exactly. I mentioned the other stuff (like local sip server) because there was another poster that i understood uses this. If you' ve public ips - even better, no NAT :) BUT something has to open the " holes" (pinholes) to pass voice (RTP). And this is what the SIP-ALG also does (as it also does the NATing of SIP Headers in case it' s needed). Your policy would be like int->ext sip allow with a " sip enabled" Protection profile attached to it. That should do the job -R.