Skip to main content
A
Anonymous_User
Contributor
October 7, 2010
Question

Sip INVITE headers being modified

  • October 7, 2010
  • 5 replies
  • 11184 views
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

    5 replies

    lmuir
    lmuir
    New Member
    October 8, 2010
    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?
    A
    Anonymous_UserAuthor
    Contributor
    October 10, 2010
    I tried with and without the SIP ALG enabled in the protection profile and there was no change.
    emnoc
    emnoc
    New Member
    October 8, 2010
    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.
    A
    Anonymous_UserAuthor
    Contributor
    October 10, 2010
    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
    g3rman
    New Member
    October 8, 2010
    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
    A
    Anonymous_UserAuthor
    Contributor
    October 10, 2010
    Yup I have those settings disabled. Still having issues
    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    October 11, 2010
    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
    rwpatterson
    New Member
    October 11, 2010
    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' ?
    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    October 11, 2010
    yep, sorry, cut&paste error. I' ve reposted it.
    Terms & ConditionsAccessibility statement