IP Authentication is sending local IP in the FROM field.

Discussion in '3CX Phone System - General' started by PatrickTodd, Jan 12, 2016.

Thread Status:
Not open for further replies.
  1. PatrickTodd

    Joined:
    Jan 12, 2016
    Messages:
    40
    Likes Received:
    6
    I am setting up a new 3CX server internally, and all went well till setting up the trunk; we use OneRing Networks, which is an ATT reseller so I selected ATT, no auth etc, but when making a call it keeps sending the internal 192.168.1.xx address.

    I do not have stun enabled, instead setting the public IP as static and also attempted to set static within the 'Advanced' section of the trunk. Any idea why this would be happening? I am using v14 sp2. I figured it might be the VIA field but can't change that. I really don't want to have to put this directly on an external ip without using our firewall..
     
  2. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,283
    Likes Received:
    68
    Did you change the Local LAN IP of the server after the installation by any chance or does the NIC have 2 IPs on it? Also, is the 192.168.1.xx the Local IP of the 3CX Server or is it the IP of the phone that is making the call?
     
  3. PatrickTodd

    Joined:
    Jan 12, 2016
    Messages:
    40
    Likes Received:
    6
    The 192.168.1.XX address is the static IP for the only adapter attached to the virtual machine, I followed the Hyper-V instructions for setting a static MAC address then installed the 3CX software so the IP has remained the same.

    By default it looks like stun is disabled and on the 'Network'' page it lists my static Ip in a customizable field and a dropdown with one option that lists the 192.168.1.XX IP of the local adapter.

    From the way the interface looks and the '?' hints this should be the field that sets the 'From; filed but it does not appear to be happening on the provider's end. If I edit the trunk manually to send my public IP it doesn't seem to work either, still sending my internal IP.


    Any configs or logs I could post to help diagnose?
     
  4. craigreilly

    craigreilly Well-Known Member

    Joined:
    Feb 1, 2012
    Messages:
    3,134
    Likes Received:
    211
    I've never had this issues - but usually set up an outbound Static NAT in my router.
    I think they say this is not needed, but I do it anyway out of habit as I do for Exchange.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,064
    Likes Received:
    58
    Do a wireshark capture of a call and attach. Just be Certain to edit and modify your public IP and that of the provider so that it reflects a fake but still ascertainable as to what the intent is (who is who).
     
  6. PatrickTodd

    Joined:
    Jan 12, 2016
    Messages:
    40
    Likes Received:
    6
    I have this setup in the firewall the same as I had an Asterisk unit setup with the same provider, swapping the rules over still works for the asterisk box, I use a Sophos SG230 and have Sip Helper disabled.
    I set it up for Masquerading and S - DNAT. The firewall check within 3CX gives an all clear.



    192.168.1.XX is the Internal IP of the server
    192.168.1.XXX is the Internal IP of a client running 3CX Phone provisioned as the Operator1000 ext.
    XX.XXX.X.XX is my External IP
    66.XXX.XXX.X is the Provider


    It does not look like 3CX is using my external IP in the FROM field.

    Code:
    
    
    
       M<+   ÿÿÿÿÿÿÿÿ      œ          2 \Device\NPF_{73282852-597D-4CE4-BF76-CC8337136E18}  	        not port 3389   ) 64-bit Windows Server 2012 R2, build 9600       œ      Ì      ,) íà[\©  ©   ]°tÔ5æsŠ E ›vw  €;îÀ¨’À¨
    ÈÿćŽÔINVITE sip:9PHONENUMBER@192.168.1.XX;tag3cx=b757779a7296416d82f626f86c2eec73 SIP/2.0
    Via: SIP/2.0/UDP 192.168.1.XXX:51455;rport;branch=z9hG4bKPja1dd7d8da4474f8fa7e2d10d79cf1256
    Max-Forwards: 70
    From: "Operator" <sip:1000@192.168.1.XX>;tag=e5a9073b785f433a8a9d7216277e2b10
    To: <sip:9PHONENUMBER@192.168.1.XX;tag3cx=b757779a7296416d82f626f86c2eec73>
    Contact: "Operator" <sip:1000@192.168.1.XXX:51455;rinstance=0-0c3119d9b12142ae948660786ca24656;ob>
    Call-ID: f4a4b7668fb64a1aa74ae0cf45296f1c
    CSeq: 10466 INVITE
    Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
    Supported: replaces, 100rel, timer, norefersub
    Session-Expires: 1800
    Min-SE: 90
    User-Agent: 3CXPhone for Windows 14.0.47020.0
    Content-Type: application/sdp
    Content-Length:   353
    
    v=0
    o=- 3661616175 3661616175 IN IP4 192.168.1.XXX
    s=pjmedia
    b=AS:84
    t=0 0
    a=X-nat:0
    m=audio 42008 RTP/AVP 0 8 3 96
    c=IN IP4 192.168.1.XXX
    b=TIAS:64000
    b=AS:84
    a=rtcp:42009
    a=sendrecv
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:3 GSM/8000
    a=rtpmap:96 telephone-event/8000
    a=fmtp:96 0-15
    m=video 0 RTP/AVP 31
    c=IN IP4 127.0.0.1
       Ì     „      ,) ÷e]\c  c  tÔ5æsŠ ]° E ULÁ  €  À¨
    À¨’ÄÈÿA†?SIP/2.0 407 Proxy Authentication Required
    Via: SIP/2.0/UDP 192.168.1.XXX:51455;rport=51455;branch=z9hG4bKPja1dd7d8da4474f8fa7e2d10d79cf1256
    Proxy-Authenticate: Digest nonce="414d535c0ca62d0c42:35c8a3b2925c6aecbe2144d50fab7d80",algorithm=MD5,realm="3CXPhoneSystem"
    To: <sip:9PHONENUMBER@192.168.1.XX;tag3cx=b757779a7296416d82f626f86c2eec73>;tag=4f644071
    From: "Operator"<sip:1000@192.168.1.XX>;tag=e5a9073b785f433a8a9d7216277e2b10
    Call-ID: f4a4b7668fb64a1aa74ae0cf45296f1c
    CSeq: 10466 INVITE
    User-Agent: 3CXPhoneSystem 14.0.47020.408 (46852)
    Content-Length: 0
    
     „           ,) ûi]\å  å   ]°tÔ5æsŠ E ×vx  €>±À¨’À¨
    ÈÿÄÃm ACK sip:9PHONENUMBER@192.168.1.XX;tag3cx=b757779a7296416d82f626f86c2eec73 SIP/2.0
    Via: SIP/2.0/UDP 192.168.1.XXX:51455;rport;branch=z9hG4bKPja1dd7d8da4474f8fa7e2d10d79cf1256
    Max-Forwards: 70
    From: "Operator" <sip:1000@192.168.1.XX>;tag=e5a9073b785f433a8a9d7216277e2b10
    To: <sip:9PHONENUMBER@192.168.1.XX;tag3cx=b757779a7296416d82f626f86c2eec73>;tag=4f644071
    Call-ID: f4a4b7668fb64a1aa74ae0cf45296f1c
    CSeq: 10466 ACK
    Content-Length:  0
    
            è      ,) Wk]\Å  Å   ]°tÔ5æsŠ E ·vy@ €úÚÀ¨’À¨
    Éħ ia‹$»ºP û²–  INVITE sip:9PHONENUMBER@192.168.1.XX;tag3cx=b757779a7296416d82f626f86c2eec73 SIP/2.0
    Via: SIP/2.0/TCP 192.168.1.XXX:51474;rport;branch=z9hG4bKPj7e849ef789874bc2928860439fe7d494;alias
    Max-Forwards: 70
    From: "Operator" <sip:1000@192.168.1.XX>;tag=e5a9073b785f433a8a9d7216277e2b10
    To: <sip:9PHONENUMBER@192.168.1.XX;tag3cx=b757779a7296416d82f626f86c2eec73>
    Contact: "Operator" <sip:1000@192.168.1.XXX:51455;rinstance=0-0c3119d9b12142ae948660786ca24656;ob>
    Call-ID: f4a4b7668fb64a1aa74ae0cf45296f1c
    CSeq: 10467 INVITE
    Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
    Supported: replaces, 100rel, timer, norefersub
    Session-Expires: 1800
    Min-SE: 90
    User-Agent: 3CXPhone for Windows 14.0.47020.0
    Proxy-Authorization: Digest username="1000", realm="3CXPhoneSystem", nonce="414d535c0ca62d0c42:35c8a3b2925c6aecbe2144d50fab7d80", uri="sip:9PHONENUMBER@192.168.1.XX;tag3cx=b757779a7296416d82f626f86c2eec73", response="f89a4c56524f6013f6e2e038482864a0", algorithm=MD5
    Content-Type: application/sdp
    Content-Length:   353
    
    v=0
    o=- 3661616175 3661616175 IN IP4 192.168.1.XXX
    s=pjmedia
    b=AS:84
    t=0 0
    a=X-nat:0
    m=audio 42008 RTP/AVP 0 8 3 96
    c=IN IP4 192.168.1.XXX
    b=TIAS:64000
    b=AS:84
    a=rtcp:42009
    a=sendrecv
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:3 GSM/8000
    a=rtpmap:96 telephone-event/8000
    a=fmtp:96 0-15
    m=video 0 RTP/AVP 31
    c=IN IP4 127.0.0.1
       è           ,) :‚]\p  p  tÔ5æsŠ ]° E bLÂ@ €  À¨
    À¨’»ÈþÒRq¼™’Pû…A    ­¥åͼ]ókD	}§Vù|ÓÇ<®L	#´Ñ¾à,œ—7æ‹ùø,VÁaÔ$Y«—ÀÖ'7Ùð'DÁu8öA ÆK²€F~j¸œU‘(Aè=Tc6áìˆÈ[ŠëØ>Fiʬ¨±ò~õ êîØ1åGhŒ›©óûû^èx–ÒŠß[õ¿Ú*¥CtÏ/m—	J·½¯“ª«M^`mÆHqƒPE@:Œþ¼)œû6>ºéÇÂÄÞbDÚ!øìÏÚ	£Ì¾‡jo¸úž-\sr쾝K(‘p9xaÒ¤<˜çjµš‹yFǤᐧ˜ê˳¤É¨øo÷ÿˆ/’N­]¯TU§<¬GÓ‰g$ò¨÷c¸â¸ÅFÐßµwÔ|là›A°Ptr+)ž¢ú°Á7e5¹Ý     À       ,) ~ƒ]\        tÔ5æsŠ ]° E  ’LÃ@ €  À¨
    À¨’»ÈþÒRrö™’Pû„q    Q†h$¶€…s
    è´OMKXê~r÷åíàmæåÍ @ñýéÁ¬÷X¹œ=®‹€Àz„9¶Ç鬾œ©P¸zjFs#CIœÜSHâŒ!DÖ…ÏDƒ;< ÌÞ-ɉ“Ycχ#À      |       ,) 4„]\\   \    %"Ÿ* ]° E  N	²@ €  À¨
    À¨2 PÎXÂuM«PýƒÍ  20
    28
    Ђ
    *
    X
    |             ,) ¼…]\€  €  tÔ5æsŠ ]° E rLÅ@ €  À¨
    À¨’»ÈþÒRs`™’Pû…Q    B¹:œe§#øRIƒ;Ù	öùšwUNâ(’Á€d]l¾ 1ÌL(·R»ç´x'¸lãnwzWzåvúc`<¬&Ï<;-ÁíÁ'@|äG«ßÖôÜÙåü}µÊч¾;õNöXQö˹‚!² ÐRaöÚØ=Éžãáíhõ1Ãô\ÑEG¥W°	;7# VðÇ¢	UÝ ø{‘fXpÔ7Ê S`ÅþCá NþN…‰’—8­ûKEè‚bÒB9I힁|EŸ•­²k­;Á£±y»wÓ—·´UÐ`€éëf†¢«^‹Ðqp”ž>üy…¹n:»ê…òŒzx…ªwj	ÖEÿ:ÿøƒºóNŸ~\ÅÅÞ¤sIDlãá°§ÒŸÒVÂ6½[¢ˆ‹$+HÏ'êkä<$å)ü9E…Ü:ÿ      \       ,) *†]\<   <    ]°tÔ5æsŠ E  (vz@ € iÀ¨’À¨
    Èþ»™’ÒRs`P jÎ        \      X      ,) ¸†]\5  5   %"Ÿ* ]° E '	´@ €  À¨
    À¨2 PÎXÂ;uM«Pý„¦  f9
    244
    Ђ
    íæ*ßÚzÓÎ1 (0 : B H R Z9PHONENUMBER` j
    à
      ($0x‚1000ŠOperator’ ˜² º1000À ÊLsip:1000@192.168.1.XXX:51455;rinstance=0-0c3119d9b12142ae948660786ca24656;obÐ Ú b757779a7296416d82f626f86c2eec73
       X     \       ,) ¯ˆ]\<   <    ]° %"Ÿ* E  (	@ €n.À¨2À¨
    Î PuM«XÃ:P äz        \      X       ,) Z4^\6   6   tÔ5æsŠ ]° E  (LÇ@ €  À¨
    À¨’ÄÉ‹$»º§ nðP„    X      \       ,) LO^\<   <    ]°tÔ5æsŠ E  (v{@ € hÀ¨’À¨
    Èþ»™’ÒRtªP ÿi…        \      ¸      ,) Ë_\—  —   ŒXØ ]° E ‰&¥  €  À¨
    B»³ÄÄuºöINVITE sip:PHONENUMBER@66.XXX.XXX.X:5060 SIP/2.0
    Via: SIP/2.0/UDP 192.168.1.XX:5060;branch=z9hG4bK-d8754z-7c183e55150a9e64-1---d8754z-;rport
    Max-Forwards: 70
    Contact: <sip:7066138759@XX.XXX.X.XX:5060>
    To: <sip:PHONENUMBER@66.XXX.XXX.X:5060>
    From: "7066138759"<sip:7066138759@66.XXX.XXX.X:5060>;tag=ce174e4d
    Call-ID: YmQ1OWYwYTU0OWM5YTgxOTJlZGFlY2YyMDg5YjA2NDU.
    CSeq: 1 INVITE
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
    Content-Type: application/sdp
    Supported: replaces
    User-Agent: 3CXPhoneSystem 14.0.47020.408 (46852)
    Content-Length: 276
    
    v=0
    o=3cxPS 211644579840 241155702785 IN IP4 XX.XXX.X.XX
    s=3cxPS Audio call
    c=IN IP4 XX.XXX.X.XX
    t=0 0
    m=audio 9004 RTP/AVP 0 8 18 101
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:18 G729/8000
    a=fmtp:18 annexb=no
    a=rtpmap:101 telephone-event/8000
    a=sendrecv
     ¸     Ä      ,) _\¢  ¢  tÔ5æsŠ ]° E ”LÈ@ €  À¨
    À¨’ÄÉ‹$»º§ nðP…s  SIP/2.0 100 Trying
    Via: SIP/2.0/TCP 192.168.1.XXX:51474;rport=51474;branch=z9hG4bKPj7e849ef789874bc2928860439fe7d494;alias
    To: <sip:9PHONENUMBER@192.168.1.XX;tag3cx=b757779a7296416d82f626f86c2eec73>
    From: "Operator" <sip:1000@192.168.1.XX>;tag=e5a9073b785f433a8a9d7216277e2b10
    Call-ID: f4a4b7668fb64a1aa74ae0cf45296f1c
    CSeq: 10467 INVITE
    Content-Length: 0
    
      Ä     Ô      ,) K_\³  ³   ]° ŒXØ E ¥  @ <…ØB»³À¨
    ÄÄ‘ýSIP/2.0 403 Forbidden-Source Endpoint Lookup Failed
    Via: SIP/2.0/UDP 192.168.1.XX:5060;rport=1484;received=XX.XXX.X.XX;branch=z9hG4bK-d8754z-7c183e55150a9e64-1---d8754z-
    From: "7066138759" <sip:7066138759@66.XXX.XXX.X:5060>;tag=ce174e4d
    Call-ID: YmQ1OWYwYTU0OWM5YTgxOTJlZGFlY2YyMDg5YjA2NDU.
    CSeq: 1 INVITE
    To: <sip:PHONENUMBER@66.XXX.XXX.X:5060>;tag=3661634160-58566
    Content-Length: 0
    
     Ô     À      ,) ‘_\       ŒXØ ]° E ’&¦  €  À¨
    B»³ÄÄ~¸ÿACK sip:PHONENUMBER@66.XXX.XXX.X:5060 SIP/2.0
    Via: SIP/2.0/UDP 192.168.1.XX:5060;branch=z9hG4bK-d8754z-7c183e55150a9e64-1---d8754z-;rport
    Max-Forwards: 70
    To: <sip:PHONENUMBER@66.XXX.XXX.X:5060>;tag=3661634160-58566
    From: "7066138759"<sip:7066138759@66.XXX.XXX.X:5060>;tag=ce174e4d
    Call-ID: YmQ1OWYwYTU0OWM5YTgxOTJlZGFlY2YyMDg5YjA2NDU.
    CSeq: 1 ACK
    Content-Length: 0
    
    À     l       ,) !™\  Counters provided by dumpcap  ,) ·ï=\  ,) !™\  :                     l   
     
  7. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,283
    Likes Received:
    68
    This seems to be the INVITE the PBX sent to the Provider:

    Code:
    Via: SIP/2.0/UDP 192.168.1.XX:5060;branch=z9hG4bK-d8754z-7c183e55150a9e64-1---d8754z-;rport
    Max-Forwards: 70
    Contact: <sip:7066138759@XX.XXX.X.XX:5060>
    To: <sip:PHONENUMBER@66.XXX.XXX.X:5060>
    From: "7066138759"<sip:7066138759@66.XXX.XXX.X:5060>;tag=ce174e4d
    Call-ID: YmQ1OWYwYTU0OWM5YTgxOTJlZGFlY2YyMDg5YjA2NDU.
    CSeq: 1 INVITE
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
    Content-Type: application/sdp
    Supported: replaces
    User-Agent: 3CXPhoneSystem 14.0.47020.408 (46852)
    Content-Length: 276
    
    v=0
    o=3cxPS 211644579840 241155702785 IN IP4 XX.XXX.X.XX
    s=3cxPS Audio call
    c=IN IP4 XX.XXX.X.XX
    t=0 0
    m=audio 9004 RTP/AVP 0 8 18 101
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:18 G729/8000
    a=fmtp:18 annexb=no
    a=rtpmap:101 telephone-event/8000
    a=sendrecv
    In this snippet I see:
    1) Contact: <sip:7066138759@XX.XXX.X.XX:5060>
    The Contact field tells the other party where to send SIP messages back to, so by the time it has XX.XXX.X.XX (which means you Public IP) and 5060, it looks correct.
    2) c=IN IP4 XX.XXX.X.XX
    t=0 0
    m=audio 9004 RTP/AVP 0 8 18 101

    This is were the PBX is telling the other party where to send audio as well as what codecs to use, where again it has XX.XXX.X.XX and requesting audio on port 9004.

    In which SIP field do you see the PBX requesting any information on its Local IP?
    Just an update, the 'Via' header is not supposed to be used for that, I think I recall seeing an RFC document at some point saying as much.
     
  8. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,064
    Likes Received:
    58
    I agree with Nick_D, but........agree or not about the proper protocol/format, there are some who want to see something else. I did an install last month involving a small telephone co-op. They provided credentials for a peer trunk and no matter what I did, I could not get an outbound call to function. I hooked up an Asterisk system and had no issue, but finally the issue came up that I was actually connecting in to a SBC at their site and the SBC did not like the VIA as it was showing the local IP. Comparing captures from Asterisk to 3CX showed us that the only difference was in the VIA.

    To get around the issue I set up the provider as Gamma (an approved UK provider), as this is the only one that unlocks the VIA field so you can put the public IP in. This did the trick for this particular install. Fortunately, the local telco guys were really helpful and provided me with the error messages that they saw. I contacted 3CX support on the matter and they are the ones who steered me to the Gamma solution.

    Do not know if this will help..but maybe?
     
  9. PatrickTodd

    Joined:
    Jan 12, 2016
    Messages:
    40
    Likes Received:
    6
    Thankyoumuch, I am pretty sure that is the issue, I'll see if my telco can make an exception or I suppose I can try to use the gamma provider then modify it to match att as much as I can.

    I understand the VIA is suppose to conform to standard, but it seems like we should have the ability to modify it if we have to. Strange that VIA would even include the local IP..
     
  10. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,064
    Likes Received:
    58
    Generally the VIA will contain a local IP. The VIA is intended to show a record of the route. So, for example, the phone from which the call originated will be to 3CX and then to/from possibly an SBC and then to a provider. Each will have its own Invite which reflect its in C= and each will add a entry into the VIA so that a record of how the call route was established can be traced back.

    http://www.3cx.com/blog/voip-howto/sip-invite-header-fields/
     
  11. PatrickTodd

    Joined:
    Jan 12, 2016
    Messages:
    40
    Likes Received:
    6
    Wait, by SBC do you mean session border controller?

    If I am understanding correctly, If I were to set one up my provider might would see the IP of the SBC as the most recent hop in the VIA header instead of my firewalled 3cx server correct? Sounds like that might neatly sidestep my problem while also allowing for a bit better transport over remote networks that might not have SIP properly configured on the gateway.

    How intensive are the SBC processor requirements; would I need parity with the main server or is it lighter weight since it is essentially a tunneler?

    I might have an intel NUC lying around I could stick on my outside switch for that.
     
  12. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,064
    Likes Received:
    58
    Sorry for the late reply, but yes, SBC = session border controller.

    If I were you, I would simply put in my public IP in the VIA field and see if that satisfies the provider and gets you a working system.

    The addition of a SBC may not be necessary and certainly adds costs as well as complexity.
     
  13. ian.watts

    ian.watts Active Member

    Joined:
    Apr 8, 2011
    Messages:
    532
    Likes Received:
    0
    This seems akin to that problem I ended up with after changing the WAN IP address on a multi-homed PBX.. there I had to look for it in the custom parameters.. the RTP sessions were trying to bind to that old address.

    Look for the LAN IP accordingly, you may find what you're looking for didn't get updated after perhaps you added the WAN IP stuff post-install.
     
  14. PatrickTodd

    Joined:
    Jan 12, 2016
    Messages:
    40
    Likes Received:
    6
    I was able to get the provider to authenticate vs a different field.

    Thanks all for the help and replies, mods please close :)
     
  15. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,283
    Likes Received:
    68
    Locking Thread.
     
Thread Status:
Not open for further replies.