Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
hrodriguez
New Contributor

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:

[ul]
  • One out rule with this parameters:[ul]
  • 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[/ul]
  • One in rule with this parameters:[ul]
  • 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[/ul]
  • One in rule with this parameters:[ul]
  • 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[/ul][/ul][ul]
  •  One virtual IP with this parameters:[ul]
  • 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[/ul]
  • 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[/ul]

    I don't know what Is happening, I feel like I was in the middle of a desert.

     

    Thank you!!

  • 18 REPLIES 18
    amitkor
    New Contributor

    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/

     

     

    ShrewLWD

    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.

    amitkor

    ShrewLWD wrote:
    It'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.

    emnoc
    Esteemed Contributor III

    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 

    StrongSwan  

    PCNSE NSE StrongSwan
    hrodriguez
    New Contributor

    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

    Christopher_McMullan

    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&d... 0 65063220"

    Paste the quote contents into the address bar, or else search for 'fgt2eth' at kb.fortinet.com.

    Regards, Chris McMullan Fortinet Ottawa

    ShrewLWD

    *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!

    hrodriguez
    New Contributor

    Hi!! Finally we solved it...the problem was a double NAT that didn't work correctly...so thank you for all!!!

    faizalfaiz

    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.

    Announcements

    Select Forum Responses to become Knowledge Articles!

    Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

    Labels
    Top Kudoed Authors