SIP in nat configuration problem

[Miata]

We have a fortinet firewall: FortiGate 311B Firmware Version v5.2.3,build670 (GA) [Update] We are working in NAT configuration Poort 1 is used for management. Poort 2 is uplink to outside world The other ports are aggregated in one pipe with each of them having there own small subnet. third digit representing the port number. Registration is not ok, due to NAT problem I attached  195.207.5.83 : public ip on the internet side.  10.40.5.135 : local ip assigned to ALU equipment Fortinet firewall should do the NAT to translate the IP.  Attached trace is taken on the ALU equipment, public ip should not be seen in SIP reply messages sent to ALU equipment.  See packet 4 in register_nok_fortinet_problem.pcap  In packet 4 the ip in the contact header from the public side should be replaced by isam IP again. Now it is : sip.Contact == "<sip:01150900027@195.207.5.83:50177>;expires=120" It should be replaced by : sip.Contact == "<sip:01150900027@10.40.5.135:50177>;expires=120" SIP session Helper is disabled.

It seems the private IP is not translated anymore into the public ip. On the internet side we can see 10.40.5.135. I expect the public internet ip 195.207.5.83 would always be used at internet side.

Are we missing somehow a parameter in the configuration or is this still some firmware problem?

[emnoc]

Do you have a voip profile?

show voip profile  from cli

Is it applied ?

( e.g )

config voip profile

  edit myvoip

      config sip

         set status  enable

         set rtp enable

         set call-keepalive  120

      end

[FortiRack_Eric]

You have to use the SIP-ALG  to have rewrites of the SIP requests with the external IP address. Check the kb.fortinet.com and/or docs.fortinet.com there's an excellent artiket on SIP config

[Miata]

Would the following be of use?

http://kb.fortinet.com/kb/documentLink.do?externalID=13667

Do you have anything to hand if not?

Thank you for your help.

Regards,

Miata

[Christopher_McMullan]

The ALG (VoIP Profile) and session helpers will modify Layer-7 information in the SIP header, among other things. They are only necessary for security (VoIP Profile) or if your PBX does not already fix up SIP packets to identify phones and the PBX by their public IPs for outbound traffic. Pinholes are necessary if you need a range of ports opened inbound for media streams (RTP or otherwise), and have not already created a VIP allowing this traffic. If you don't need either function, and do not need additional security, you can safely disable the session helper completely. If you still require one (or both) of the functions the helper provides, you would need to toggle them individually under 'config system settings':

config system settings

set sip-helper {enable | disable} //--this opens pinholes

set sip-nat-trace {enable | disable} //--this performs header fixup

I've really over-simplified the VoIP profile, since it's not just for security (it can perform far more granular modifications on SIP traffic), but for our purposes here, we likely only need to focus on the two core functions of the helper or the ALG.

The article you cited is very old. I think the guide mentioned earlier is a better choice: http://docs.fortinet.com/d/fortigate-voip-solutions-sip-2

[Miata]

Thanks for your response.

So I need to enable this session helper(ALG) to solve my issue?

Regards Miata

[Christopher_McMullan]

You need to find out through your own troubleshooting (or with the help of TAC) and the documentation for your phone system what the phones and PBX take care of, and what they require the firewall or outside devices to modify.

Just be careful: what we call the VoIP profile is what is generally understood to be an ALG. The session helpers would not completely qualify, since they only perform their two strict functions: header fixup and pinholes. We don't refer to the session helpers when we mention an ALG.

If you turn them completely off, and things still don't work, turn the two features back on one by one to see if they make a difference.

To disable:

config system session-helper

show //--find the ID for SIP

delete 13 //--or whatever the number is

end

config system settings

set sip-helper disable

set sip-nat-trace disable

set default-voip-alg-mode kernel-helper-based //--now, just to confuse you, the kernel helper means session helpers, and you're setting 'default-voip-alg-mode'; but that still doesn't mean the helpers are an ALG; it's just twisted FortiLogic

end

exec reboot

y

Test a call once the FortiGate reboots, then assuming one-way audio or remaining issues:

config system session-helper

edit 13

set protocol 17

set port 5060

end

config system settings

set sip-helper enable

end

exec reboot

y

Test a call after rebooting. If it fails:

config system settings

set sip-helper disable

set sip-nat-trace enable

end

Test a call (no need to reboot this time). If it fails:

config system settings

set sip-helper enable

end

Just to get the same result twice (a good sign of cause and effect!). Test a call. If it fails:

config system settings

set default-voip-alg-mode proxy

end

Then add a VoIP profile to the relevant firewall policy/policies and test again. Open a ticket with TAC if the default profile doesn't work right out of the box, to have someone work alongside you to tweak profile settings until the calls work.

[Silver]

Hi,

Am getting the same issues with nat. my wan port configured with a public ip address and my lan configured as link aggregation from fortinet appliance to core switch and different vlan configured. my IP Phone is on a different voice vlan. my phone configured with 2 sip account line 1 sip account for local and another line 2 sip for inter nation. the line 1 is working fine register correctly but the line 2 sip registration failed. all my ip phone configure with private ip address and nat to the wan interface where the public ip are configured.  Several time am getting problem with registration. sometime the registration is being done correctly and sometime it dis register by itself. i noticed also whenever i remove the nat under the policy from ip phone to wan i start getting sip traffic and whenever i added the nat i start seeing the sip traffic.

i have even disable the session helper / disable nat trace / disable sip rtp / disable sip help .

anyone can tell me why and what i need to do to sort out this issues as its very urgent. 

[Silver]

Any help plz

[emnoc]

So is you problem sip registeration? Have you taken pcaps to validate the  SIP registration and what's sent to the UAS or UAProxy?

You might be able to isolate a lot by looking for any SIP status.codes. If you don't get a status.code back in a respond that's a good indication that 1> your sip register never make it or 2> the response was dropped at the  firewall. Even a bad SIP registery account will generate a 40X code.

i.e ( here's a proper SIP traffic taken at the SIP client , I was testing newer codecs btw )

tshark -tad -r 711a.pcap -2 -R 'sip'   1 2015-05-24 17:29:56.160484  10.10.80.16 -> 86.64.162.35 SIP/SDP 766 Request: INVITE sip:500@ekiga.net |   2 2015-05-24 17:29:56.357503 86.64.162.35 -> 10.10.80.16  SIP 544 Status: 407 Proxy Authentication Required |   3 2015-05-24 17:29:56.358815  10.10.80.16 -> 86.64.162.35 SIP 394 Request: ACK sip:500@ekiga.net |   4 2015-05-24 17:29:56.359450  10.10.80.16 -> 86.64.162.35 SIP/SDP 974 Request: INVITE sip:500@ekiga.net |   5 2015-05-24 17:29:56.557435 86.64.162.35 -> 10.10.80.16  SIP 382 Status: 100 Giving a try |   6 2015-05-24 17:29:56.567424 86.64.162.35 -> 10.10.80.16  SIP/SDP 833 Status: 200 OK |   7 2015-05-24 17:29:56.575456  10.10.80.16 -> 86.64.162.35 SIP 517 Request: ACK sip:500@86.64.162.35:5081 |   8 2015-05-24 17:30:35.919633  10.10.80.16 -> 86.64.162.35 SIP 733 Request: BYE sip:500@86.64.162.35:5081 |   9 2015-05-24 17:30:36.222197 86.64.162.35 -> 10.10.80.16  SIP 505 Status: 200 OK |

That's above is a proper sip-signaling to my ekiga net and with the correct sip.Status-Code responses.

That was done thru a fortigate firewall with a simple fwpolicy and nothing special. If the problem is audio,  than the ALG needs to be looked at and ensure that the RTP pinholes are opening to allow your media path. i

If it's codec issues, than investigate the SIP client ( firewall has nothing todo with codec offerings btw )

So you need to imho 1> stop enable/disable things  2> build a plan to isolate what's really going  via pcaps outside of the firewall 3> if your firewall supports pcap creation execute a capture  and review the request & response 4>  ensure you meet the SIP min register intervals or adjust the  timeout value in the firewall TTL, but I find it much easier just to increase the sip UAC sip register interval and/or  sip keep-alives 

YMMV on the SIP client depending on ( hardware vrs softclient ) and what SIP-KAs structure or register that it supports.

5> ask the far end what your sending. That could shed big clues and ensure that your SIP signalling is making thru and now you nee to find out the reasons.

[Silver]

Hi Emnoc,

Thank you very much for your response. Let me explain in details my network and issues.

1) I have 2 different ISP connected on my FGT

2) ISP 1 with Public ip address configured on wan1 and connected to ISP Router

3)ISP 2 with private ip address configured on wan2 and connected to ISP Router

4) I have several vlan's voice , Data ,  wireless , cctv etc

5) The problem we are  facing is about the phone registration with our server Cloud Provider.

6) All my Telephone system are configured with a sip account

7) we have dedicated ISP1 only for SIP traffic and VPN Connection

8) A PBR has been configured to redirect all the voice traffic via the ISP1 

9) Sometime the phone register via the isp and disconnect

10 But we have also try to register the phone with ISP 2 without any problem phone are registered very quick and can make call.

11) Our ISP 1 configured all ports open nothing block etc

12) I noticed also whenever i remove the nat on the policy iphone to isp 1 policy i start getting more sip traffic but if we again put the nat not same result.

where do you think the problem could be.

can you send me any debug command so that i can try and provide you the output you can have a look and advise.

Thanks awaiting your reply!