Problem with SIP traffic

[hrodriguez]

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

[amitkor]

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]

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.

[hrodriguez]

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.

[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]

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.