• V20: 3CX Re-engineered. Get V20 for increased security, better call management, a new admin console and Windows softphone. Learn More.

IP Authentication is sending local IP in the FROM field.

Status
Not open for further replies.

PatrickTodd

Customer
Advanced Certified
Joined
Jan 12, 2016
Messages
40
Reaction score
7
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..
 
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?
 
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?
 
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.
 
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).
 
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:[email protected];tag3cx=b757779a7296416d82f626f86c2eec73 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.XXX:51455;rport;branch=z9hG4bKPja1dd7d8da4474f8fa7e2d10d79cf1256
Max-Forwards: 70
From: "Operator" <sip:[email protected]>;tag=e5a9073b785f433a8a9d7216277e2b10
To: <sip:[email protected];tag3cx=b757779a7296416d82f626f86c2eec73>
Contact: "Operator" <sip:[email protected]: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:[email protected];tag3cx=b757779a7296416d82f626f86c2eec73>;tag=4f644071
From: "Operator"<sip:[email protected]>;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:[email protected];tag3cx=b757779a7296416d82f626f86c2eec73 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.XXX:51455;rport;branch=z9hG4bKPja1dd7d8da4474f8fa7e2d10d79cf1256
Max-Forwards: 70
From: "Operator" <sip:[email protected]>;tag=e5a9073b785f433a8a9d7216277e2b10
To: <sip:[email protected];tag3cx=b757779a7296416d82f626f86c2eec73>;tag=4f644071
Call-ID: f4a4b7668fb64a1aa74ae0cf45296f1c
CSeq: 10466 ACK
Content-Length:  0

        è      ,) Wk]\Å  Å   ]°tÔ5æsŠ E ·vy@ €úÚÀ¨’À¨
Éħ ia‹$»ºP û²–  INVITE sip:[email protected];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:[email protected]>;tag=e5a9073b785f433a8a9d7216277e2b10
To: <sip:[email protected];tag3cx=b757779a7296416d82f626f86c2eec73>
Contact: "Operator" <sip:[email protected]: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:[email protected];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:[email protected]: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:[email protected]: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:[email protected]:5060>
To: <sip:[email protected]:5060>
From: "7066138759"<sip:[email protected]: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:[email protected];tag3cx=b757779a7296416d82f626f86c2eec73>
From: "Operator" <sip:[email protected]>;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:[email protected]:5060>;tag=ce174e4d
Call-ID: YmQ1OWYwYTU0OWM5YTgxOTJlZGFlY2YyMDg5YjA2NDU.
CSeq: 1 INVITE
To: <sip:[email protected]:5060>;tag=3661634160-58566
Content-Length: 0

 Ô     À      ,) ‘_\       ŒXØ ]° E ’&¦  €  À¨
B»³ÄÄ~¸ÿACK sip:[email protected]: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:[email protected]:5060>;tag=3661634160-58566
From: "7066138759"<sip:[email protected]:5060>;tag=ce174e4d
Call-ID: YmQ1OWYwYTU0OWM5YTgxOTJlZGFlY2YyMDg5YjA2NDU.
CSeq: 1 ACK
Content-Length: 0

À     l       ,) !™\  Counters provided by dumpcap  ,) ·ï=\  ,) !™\  :                     l
 
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:[email protected]:5060>
To: <sip:[email protected]:5060>
From: "7066138759"<sip:[email protected]: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:[email protected]: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.
 
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?
 
lneblett said:
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.

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..
 
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/
 
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.
 
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.
 
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.
 
I was able to get the provider to authenticate vs a different field.

Thanks all for the help and replies, mods please close :)
 
Locking Thread.
 
Status
Not open for further replies.
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.