Hot!Problem with SIP traffic

Author
hrodriguez
New Member
  • Total Posts : 3
  • Scores: 0
  • Reward points: 0
  • Joined: 2014/10/28 08:51:25
  • Status: offline
2014/10/28 09:27:00 (permalink) 4.0MR2
0

Problem with SIP traffic

Hi everyone

It's my first post, I readed a lot of this in Mr Google but I haven't been able to resolve my problem so, I decided to explain here with the hope that you may be able to help me.
The problem is that when I call to some number, the receptor doesn't listen anything, but I listen all. I talked with Fortigate support and them redirected me to this KB but when I applied this, I has started to get worse. Now I don't listen anything when I call someone
 
The actual configuration is:
  • One out rule with this parameters:
    • Source Interfaz: Internal
    • Source Addres: Alcatel PBX
    • Destination Interface: WAN2
    • Destination Adress: All
    • Schedule: Always
    • Service: SIP
    • Enable Nat
    • UTM
    • Protocol Options: default
    • Enable VoIP: VoIP Profile
  • One in rule with this parameters:
    • Source Interfaz: WAN2
    • Source Addres: all
    • Destination Interface: Internal
    • Destination Adress: Alcatel PBX
    • Schedule: Always
    • Service: SIP
    • Enable Nat
    • UTM
    • Protocol Options: default
    • Enable VoIP: VoIP Profile
  • One in rule with this parameters:
    • Source Interfaz: WAN2
    • Source Addres: all
    • Destination Interface: Internal
    • Destination Adress: SIP_Proxy_VIP
    • Schedule: Always
    • Service: SIP
    • Enable Nat
    • UTM
    • Protocol Options: default
    • Enable VoIP: VoIP Profile
  •  One virtual IP with this parameters:
    • Name: SIP_Proxy_VIP
    • External Interface: WAN2
    • Static Nat
    • External IP: 0.0.0.0
    • Mapped IP Addres: IP Alcatel PBX
    • Port Forwarding
    • External Service Port: 5060
    • Map to Port: 5060
  • And the VoIP profile has this edit "VoIP_Profile"
                config sip
                    set rtp disable
                    set register-rate 100
                    set invite-rate 100
                    set block-long-lines disable
                    set block-unknown disable
                    set log-violations enable
                    set log-call-summary disable
                end
I don't know what Is happening, I feel like I was in the middle of a desert.
 
Thank you!!
post edited by hrodriguez - 2014/10/28 10:02:29
#1

14 Replies Related Threads

    amitkor
    New Member
    • Total Posts : 13
    • Scores: 0
    • Reward points: 0
    • Joined: 2014/09/28 08:41:49
    • Status: offline
    Re: Problem with SIP traffic 2014/10/28 11:31:12 (permalink)
    0
    The conversation it self usually uses UDP ports 10000-20000. you only allowed port 5060.
    From WAN to Internal, you only need VIP. When using a VIP, the policy is limited to the ports in the VIP, so you dont need to limit it further in the service.
     
     
    Have you tried to disable SIP ALG?
    http://www.3cx.com/blog/docs/disable-sip-alg-on-fortigate/
     
     
    post edited by amitkor - 2014/10/28 11:37:49
    #2
    ShrewLWD
    Gold Member
    • Total Posts : 147
    • Scores: 3
    • Reward points: 0
    • Joined: 2009/04/23 08:16:54
    • Status: offline
    Re: Problem with SIP traffic 2014/10/28 14:01:40 (permalink)
    0
    It's frustrating that, in many SIP related issues, the first answer is to disable SIP on a Fortigate.
    It's more frustrating that, in many of our cases, that turns out to be the solution!  We have tried, then disabled, SIP in 4.3, 5.0 and now recently in 5.2
     
    It should be noted in those instructions that, while you MUST reboot at least once, the reboot does not have to occur in the instructions listed.  I typically make all the changes, then reboot at the end.
    #3
    emnoc
    Expert Member
    • Total Posts : 5123
    • Scores: 322
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    Re: Problem with SIP traffic 2014/10/28 23:57:13 (permalink)
    0
    All good advice upto this point and one more issue, on the  policy in with the VIP you don't need NAT enabled. So you can remove that from the policy.The  VIP manages the NAT by that process.
     
    And always remember to  use diag debug flow for flow analysis between the alcatelPBX and destination. It may shed some serious light on other issues.
     

    PCNSE,  NSE , Forcepoint ,  StrongSwan Specialist
    #4
    hrodriguez
    New Member
    • Total Posts : 3
    • Scores: 0
    • Reward points: 0
    • Joined: 2014/10/28 08:51:25
    • Status: offline
    Re: Problem with SIP traffic 2014/10/29 02:02:26 (permalink)
    0
    Hi Amiktor!
     
    Yes I have the SIP ALG disable:
    XXX (settings) # get 
    [...]
    sip-helper : disable
    sip-nat-trace : disable
    status : enable
    sip-tcp-port : 5060
    sip-udp-port : 5060
    [...]
     
    In the VoIP profile also:
    XXX (VoIP_Profile) # get
    name : VoIP_Profile
    comment : (null)
    sip:
    status : enable
    rtp : disable
    [...]
     
    Now, I modified the VIP with this parameters 
    External IP: public IP
    Mapped IP: Alcatel PBX IP
    Port Forwarding
    Protocol UPD
    External Servie Port: 5060-65535
    Map to Port: 5060-65535
     
    Also, the VIP policy has been modified with no NAT, but I'm not sure if the UTM profiles have to be enable and if Is needed SIP service or Any service
    post edited by hrodriguez - 2014/10/29 02:08:27
    #5
    amitkor
    New Member
    • Total Posts : 13
    • Scores: 0
    • Reward points: 0
    • Joined: 2014/09/28 08:41:49
    • Status: offline
    Re: Problem with SIP traffic 2014/10/29 02:05:56 (permalink)
    0
    ShrewLWDIt's frustrating that, in many SIP related issues, the first answer is to disable SIP on a Fortigate.

    Its not just with Fortigate. In every issue with SIP i disable SIP helper, regardless of vendor. Usually works.
    #6
    Christopher McMullan_FTNT
    Gold Member
    • Total Posts : 415
    • Scores: 34
    • Reward points: 0
    • Joined: 2014/09/08 08:00:33
    • Status: offline
    Re: Problem with SIP traffic 2014/10/29 05:26:50 (permalink)
    0
    I'll weigh in here...
     
    SIP presents two problems for firewalls, broadly speaking:
    (1) It is used to initiate a media stream using other high, random ports, which may include a session initiated inbound. Unless you port forward the whole defined range (ports 10000-20000, e.g.), effectively opening a wide swath of the firewall to traffic, the firewall needs a way to intelligently open "pinholes" for this media stream while the SIP signalling indicates a call is actively using those ports, then close the session when the call completes.
     
    (2) SIP contains information about the phones, PBX, etc. at Layer-7 which may need to be modified in transit in order to be routable for return traffic. If your PBX and phones have private IPs, in a number of places in the SIP header, they will identify themselves with those private IPs. If a remote phone wants to respond to an INVITE to a phone call, all it has is the private IPs at Layer-7. The firewall may be required to change this information to the public IP of the outgoing interface if no one else is doing it already.
     
    "IF NO ONE ELSE IS DOING IT ALREADY"...
     
    Many phone systems will take care of these functions by using a STUN server or static settings to discover the public IP a phone or PBX is behind and modify the Layer-7 information before it even hits the firewall. Many systems will also send an outbound packet with the source and destination ports the media stream will use when initiated, and in this way, "punch a hole" through the firewall. If either or both of these conditions are met by the phone system, there is no need for the firewall to get involved.
     
    The session helper is turned on by default on the FortiGate, which means it will listen for all UDP port 5060 traffic (this can be changed under 'config system session-helper'). The kernel can parse SIP traffic: it is aware of the structure, and can look for Media Port or Requested Port information. It will also examine the From:, Contact:, VIA:, and other fields for the IPs that devices identify themselves with. If the policy allowing the traffic performs DNAT, it can replace the original private IP with its own public IP.
     
    Pinholes and header fix-up: that's essentially the two functions of the session helpers, which again, are on by default.
     
    The VoIP profile (also referred to as an Application Layer Gateway, or ALG) performs the functions of the session helper, but also allows much more granular control over security and "tweaking" features. The default profile will work for many situations, but not all.
     
    Because there are so many possible topologies, configurations, and vendors, the session helpers and VoIP profiles may not be required, and may cause more trouble than they are worth: headers modified when not necessary; pinholes opened for the wrong ports.
     
    You just need to try the defaults until they don't work, turn the helper completely off, and if *that* doesn't work, run verbose packet sniffs and compare the packets between what arrives and what leaves the FortiGate. See if the original addresses are private or public. Check to see how the packets are modified on their way out. Verbose sniffs can be run in the context of a TAC case, so that you have help to run them and expert analysis.
     
    This would be the rough syntax (you have to run two separate sessions in order for the output to work in Wireshark):
    diag sniffer packet internal "host w.x.y.z" 6 0 a
    diag sniffer packet wan1 "host w.x.y.z" 6 0 a
     
    -Don't filter for port 5060 if you want to also see the RTP stream - it will use different ports
    -Filter for an unchanging, public IP for w.x.y.z, like the IP of the trunk or VoIP provider. That way, when the traffic is NATted, you will see the packet both before and after translation.
     
    This KB article provides the EXE and Perl script for converting the text-based sniff into a PCAP file for Wireshark:
    "http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=11186&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=65061635&stateId=0 0 65063220"
    Paste the quote contents into the address bar, or else search for 'fgt2eth' at kb.fortinet.com.
    #7
    ShrewLWD
    Gold Member
    • Total Posts : 147
    • Scores: 3
    • Reward points: 0
    • Joined: 2009/04/23 08:16:54
    • Status: offline
    Re: Problem with SIP traffic 2014/10/29 10:56:38 (permalink)
    0
    *LIGHTBULB*
    OK, so it's not a case of poor SIP implementation on the Fortigate, its a case of Fortigate wanting to assist in cases where it is not needed, due to feature and protocols already in place on the VOIP vendors' devices?
     
    That makes it so much easier to explain!
     
    Thanks Christopher!
    #8
    hrodriguez
    New Member
    • Total Posts : 3
    • Scores: 0
    • Reward points: 0
    • Joined: 2014/10/28 08:51:25
    • Status: offline
    Re: Problem with SIP traffic 2014/11/07 01:38:54 (permalink)
    0
    Hi!!
    Finally we solved it...the problem was a double NAT that didn't work correctly...so thank you for all!!!
    #9
    faizalfaiz
    New Member
    • Total Posts : 1
    • Scores: 0
    • Reward points: 0
    • Joined: 2015/12/29 07:38:33
    • Status: offline
    Re: Problem with SIP traffic 2015/12/29 07:42:28 (permalink)
    0
    Hello, i just want to share. Came across to this problem even after disabling SIP ALG, session helper, reboot etc. Im using 2 WANs so in order for 3cx server to maintain same IP header is by configuring policy route to VoIP SIP provider at Fortibox (internal -> Wan1). Use this command to verify the traffic #diag snif pack any 'host x.x.x.x' 4
     
    Hope this helps.
    post edited by faizalfaiz - 2015/12/29 07:48:49
    #10
    songzechun
    New Member
    • Total Posts : 1
    • Scores: 0
    • Reward points: 0
    • Joined: 2015/12/30 00:04:20
    • Status: offline
    Re: Problem with SIP traffic 2015/12/30 00:11:39 (permalink)
    0
    sometimes  , when I see the problem like this, I usually del the ALG that session-helper about sip.
    you can try it, forward your good news!
    like this:
    config system session-helper
    and del the one which have sip
     
    #11
    NothingKai
    New Member
    • Total Posts : 10
    • Scores: 0
    • Reward points: 0
    • Joined: 2016/07/07 22:53:14
    • Status: offline
    Re: Problem with SIP traffic 2016/08/05 02:11:56 (permalink)
    0
    Dear Everyone, my fortigate 100D same error.
     
    I can open port 5060. I can call, but cannot talk, cannot listen. Please help.
     
    I try use CLI console:
     
    Reopen CLI and enter the following commands – do not enter the text after //:
    1. config system session-helper
    2. show    //locate the SIP entry, usually 12, but can vary.
    3. delete 12     //or the number that you identified from the previous command.
     
    But no see SIP session. 
     
    #12
    HEMEIDY
    New Member
    • Total Posts : 3
    • Scores: 0
    • Reward points: 0
    • Joined: 2015/05/28 01:05:05
    • Status: offline
    Re: Problem with SIP traffic 2018/06/06 14:24:47 (permalink)
    0
    I HAVE SAME ISSUE
    #13
    Arasu2018
    New Member
    • Total Posts : 1
    • Scores: 0
    • Reward points: 0
    • Joined: 2018/09/05 09:16:07
    • Status: offline
    Re: Problem with SIP traffic 2018/09/05 14:43:18 (permalink)
    0
    we have the same issue with fortinet 100e .Phone line getting disconnects automatically during the call. happening not in frequent randomly happening. we tried disabling SIP-ALG but it introduce other problems like No audio so we revert back
    #14
    Zulnorain
    New Member
    • Total Posts : 3
    • Scores: 0
    • Reward points: 0
    • Joined: 2017/03/16 02:55:45
    • Status: offline
    Re: Problem with SIP traffic 2018/12/05 02:29:02 (permalink)
    0
    Hi,
     
    Did you get it resolved?. I am having the same problem with one of my clients. If you resolved it, can you tell me how you did it? 
    #15
    Jump to:
    © 2019 APG vNext Commercial Version 5.5