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

SIP ALG irrational behaviour

I have a VOIP Vlan for SIP phones behind a F60D model, with an “ALL PERMIT” policy. That’s the only way I could get my SIP phones to work as well as making sure the SIP Session-Helper was disabled and deleted from the config sys (somehow, the session-helper was triggered even if it was not included in any policy) So I create a test vlan and connect a phone to play around with SIP ALG before I could eventually apply a VOIP profile to my VOIP vlan for better security. Applying a copy of the ‘default’ VOIP profile, the phone fails the very initial REGISTER request with a ‘403 Forbidden’ response from the outside SIP server. Capturing and comparing the rejected REGISTER packet with a successful one, I could only notice one difference: This packet will be immediately replied with a ‘403 Forbidden’ from the SIP server: ….. Via: SIP/2.0/UDP 119.124.131.12:5060;branch=z9hG4bKf04e67d39a2e284a8 Sent-by Address: 119.124.131.12 ….. This packet will be eventually replied with a ‘200 OK’ from the SIP server: ….. Via: SIP/2.0/UDP 172.16.8.203:5060;branch=z9hG4bKb397f6fc09d3b97fa Sent-by Address: 172.16.8.203 ….. So the SIP server seems to reject the Registration request carrying the natted WAN IP address. I said " No problems!" , I enable the ‘no-sdp-fixup’ option which is supposed to circumvent NAT on the addresses in the SDP lines. Reboot the phone, sniff the traffic and.. good, the toggle did exactly what it says, i.e. the above two lines now list the phone private IP address leaving the rest unchanged, except that… the Fortigate and the VOIP profile policy itself, are now blocking that packet with “reason=" unrecognized-form" … Let’s try to disable the ‘block-unknown’ option: yes the packet now goes through the Fortigate except that.. this toggle completely voids the ‘no-sdp-fixup’ instruction and reset the natted IP address, so again the ‘403 forbidden’ reply from the SIP server. Already at this early point I’m not sure it is worth continuing my diagnoses with this irrational (at least to me) behavior, unless someone (I would be glad to) told me that I’m doing it wrong and advised a different route. Sherpa
6 REPLIES 6
emnoc
Esteemed Contributor III

Do you have a support contract with Fortinet? I would open a case explaining the diagnostics that you did and btw you did some nice debugging with some good learning info. 2md I would open a case explaining what you seen and done and then provide pcaps of the SIP control data for 5060. 3rd B4 you go that far have you investigate the firmware build your on and do you need to upgrade? Hopefully fortinet support might beable to shed some light.

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Faulty_Male
New Contributor III

We had a similar issue here is our TAC response - hope this helps: Thank you for contacting Fortinet TAC. As I see in the config, you have already disabled sip helper in the >> config system setting And, disable the session helper also, as given below: 2) Disable Sip Session Helper in the >> config global config system session-helper show delete <helper_number> >> delete only SIP Number end 3) A reboot of the Fortigate Unit is Necessary to take the effect 4) Run the below command : config sys global set gui-voip-profile enable end 5) Once the above is done, click on UTM > VOIP > Create New VOIP profile - Name it and do not make any changes If no changes made to the default profile, then you can also use the default voip profile
emnoc
Esteemed Contributor III

But would that work on a 60D running 5.x.x code?

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Faulty_Male
New Contributor III

But would that work on a 60D running 5.x.x code? NoImage = NoSigImage document.write(pgdCode(" <br><br><br>_____________________________<br><br>CCNP,FCNSP,FCESP,Linux+,CEH,ECSA,SCSA,SCNA,CISCA email/web <br> " ))
Not sure about the 60D - but we were running v5 when we had the same issue
Sherpa

Just for the records, I did disable/delete the SIP session-helper feature and rebooted (several times, between tests). I then started off my SIP-ALG testings with a copy of the DEFAULT VOIP-PROFILE. Actually I wasn’t totally right with my initial findings exposed above, as further investigations have determined the following: On booting, our Aastra SIP phones produce the following REGISTER header packet: (sensible values were modified): ….. Via: SIP/2.0/UDP 10.0.1.110:5060;branch=z9hG4bKb0570a3cb75d7f471 ….. Contact: " " <sip:+41443011111-00@10.0.1.110:5060;transport=udp>;expires=3600;+sip.instance=" <urn:uuid:00000000-0000-1000-8000-00085D3C27F8>" ….. With the default VOIP-PROFILE, the above REGISTER packet is blocked by the Fortigate with the message: Malformed Description: empty-quoted-string Malformed Description: invalid-quoted-string-in-display-name Block reason: unrecognized form That makes sense, given the unexplained presence of the double quotes in the Contact header. The only way I found to circumvent this misconfigured header was to disable the ‘block-unknow’ option in the VOIP-PROFILE. With this option disabled, this is how the REGISTER packet looks when it reaches the LAN interface Via: SIP/2.0/UDP 10.0.1.110:5060;branch=z9hG4bK94d1659f7b5d7a71c Contact: " " <sip:+41443011111-00@10.0.1.110:5060;transport=udp>;expires=3600;+sip.instance=" <urn:uuid:00000000-0000-1000-8000-00085D3C27F8>" and how it looks on the WAN interface, on its way to the SIP Server: Via: SIP/2.0/UDP 119.124.131.12:5060;branch=z9hG4bK94d1659f7b5d7a71c Contact: " " <sip:+41443011111-00@10.0.1.110:5060;transport=udp>;expires=3600;+sip.instance=" <urn:uuid:00000000-0000-1000-8000-00085D3C27F8>" This packets will be eventually rejected by the SIP server, most probably due to the different VIA and CONTACT values My impression is that the Fortigate bugs here: - It nats the VIA header - Further down the packet it finds a misconfigured CONTACT header - It sees the instruction to NOT TO BLOCK unknown packets - So it releases the packet immediately without finishing his job, i.e. natting the rest of the header. The result is a mismatched VIA and CONTACT information that will be rejected by the SIP server with a ‘403 Forbidden’ notification. I have setup a SIP proxy that simply removes the double quotes in the CONTACT header on the fly, before they reache the Fortigate, and that had fixed the problem, at least temporarily.
emnoc
Esteemed Contributor III

Qs are you sure this is the case? Can you try a different SIP client? ( or even a softclient ) what' s the firmware of the phones? The last message looks correct and is what the ALG is doing on the voip-profile fwiw; The via is always going to be in place by the proxy or nat' ing device(s). It' s common and expected for the VIA + Contact address to be different in a SIP INVITE . As a matter of fact multiple VIA can be present in a INVITE. The VIA just tells who/where to send the request to.

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Labels
Top Kudoed Authors