Sip INVITE headers being modified

[#1]

Hi everyone, I' m breaking my head trying to figure this out. I have a Fortigate 60B and it seems to be modifying parts of the SIP Headers. I tried disabling " sip-helper" and " sip-nat-trace" but it does not seem to be helping. I also ensured that there is no protection profile on the firewall rule. The specific headers that I' m talking about are the " From" " Contact" and " Anonymity" headers. My provider (flowroute.com) claims that they sent the packet looking like this and anything missing must be being stripped out by my Firewall: INVITE sip:************@************** SIP/2.0. Record-Route: <sip:70.167.153.130;lr>. Record-Route: <sip:216.115.69.142;lr>. Via: SIP/2.0/UDP 70.167.153.130;branch=z9hG4bK73c3.e613564d11025903295c92119be9b271.0. Via: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bK73c3.883356619b22bdd3d8c07c5ecf0503bc.0. Via: SIP/2.0/UDP 216.115.69.142;branch=z9hG4bK73c3.3d845433f085edc1e0ede5538e244ce9.0. Via: SIP/2.0/UDP 4.55.14.163:5060;branch=z9hG4bK05B640b19b831a7f023. From: " Private" <sip:+**************@4.55.14.163:5060;isup-oli=62>;tag=gK05565c95. To: <sip:***************@216.115.69.142:5060>. Call-ID: 1342517982_39619543@4.55.14.163. CSeq: 4659 INVITE. Max-Forwards: 14. P-Asserted-Identity: <sip:+***************@pstn>. Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed. Contact: " Private" <sip:+***************@4.55.14.163:5060>. Anonymity: name. Content-Length: 228. Content-Type: application/sdp. . v=0. o=- 18884 1819 IN IP4 4.55.14.130. s=-. c=IN IP4 4.55.14.130. t=0 0. m=audio 7796 RTP/AVP 0 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=maxptime:20. I am receiving it on the PBX looking like: Notice that the parts in bold above are stripped from the INVITE INVITE sip:************@************** SIP/2.0. Record-Route: <sip:70.167.153.130;lr>. Record-Route: <sip:216.115.69.142;lr>. Via: SIP/2.0/UDP 70.167.153.130;branch=z9hG4bK73c3.e613564d11025903295c92119be9b271.0. Via: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bK73c3.883356619b22bdd3d8c07c5ecf0503bc.0. Via: SIP/2.0/UDP 216.115.69.142;branch=z9hG4bK73c3.3d845433f085edc1e0ede5538e244ce9.0. Via: SIP/2.0/UDP 4.55.14.163:5060;branch=z9hG4bK05B640b19b831a7f023. From: <sip:+**************@4.55.14.163:5060;isup-oli=62>;tag=gK05565c95. To: <sip:***************@216.115.69.142:5060>. Call-ID: 1342517982_39619543@4.55.14.163. CSeq: 4659 INVITE. Max-Forwards: 14. P-Asserted-Identity: <sip:+***************@pstn>. Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed. Contact: <sip:+***************@4.55.14.163:5060>. Content-Length: 228. Content-Type: application/sdp. . v=0. o=- 18884 1819 IN IP4 4.55.14.130. s=-. c=IN IP4 4.55.14.130. t=0 0. m=audio 7796 RTP/AVP 0 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=maxptime:20. If anyone can help me figure this out it would be greatly appreciated. Thank You

[lmuir]

If there' s no protection profile and the SIP session helper is removed, then I don' t see what could be modifying the headers. Does using the SIP ALG help?

[#3]

I tried with and without the SIP ALG enabled in the protection profile and there was no change.

[emnoc]

If you want to compare pre& post firewall processing of your SIP invite, why don' t you setup a packet monitor and capture the packets upstream and downstream of the fortigate. Unless you have some type or proxy going on, then nothing should be changed in the SIP invite. Also are you sure your not being subject to any SIP attacks or forgery(spoof) ? This is UDP , so anything is possible. I would do the capture and based on what you find, & go from that point.

[#5]

Yup I think this what I' m gonna have to do, but I' m not gonna be at the physical location for a couple of days so its gonna have to wait

[g3rman]

Also take a look at this: config system settings set sip-helper disable end from http://firewallguru.blogspot.com/2008/03/sip-and-h323.html

[#7]

Yup I have those settings disabled. Still having issues

[ede_pfau]

Maybe I' m misunderstanding this, but for sniffing you don' t have to be on site. Open 2 ssh sessions to the external interface (enable ssh access for this on wan1). If possible let the ssh client copy the output to a file. Enter

diag sniffer packet internal ' sip and host x.y.z.t'  4

in one session and

diag sniffer packet wan1 ' sip and host x.y.z.t'  4

in the other. Then make a call. Compare and post here the (same) packet on internal and wan1 interface.

[rwpatterson]

ORIGINAL: ede_pfau Maybe I' m misunderstanding this, but for sniffing you don' t have to be on site. Open 2 ssh sessions to the external interface (enable ssh access for this on wan1). If possible let the ssh client copy the output to a file. Enter

diag sniffer packet internal ' sip and host x.y.z.t'  4

in one session and

diag sniffer packet internal ' sip and host x.y.z.t'  4

in the other. Then make a call. Compare and post here the (same) packet on internal and wan1 interface.

Maybe should be ' WAN1' ?

[#10]

diag sniffer packet wan1 ' sip and host x.y.z.t' 4

Thanks a ton!! I did not know about that. Just one correction the command should be... diag sniffer packet internal ' sip and host x.y.z.t' 5 if you want to see the actual packet data. The good news is that the packets are being received by the fortigate with the data missing so it seems like something on my providers end. Either way thanks a bunch for helping me out.