CHAN SIP Extension behind NAT fails to register

hlusher · October 19, 2017, 3:11pm

Have a remote office (connected via VPN) with 4 extensions that was previously working. Had to make some changes at the core with a router and some switches and somehow in the process the remote office SIP phones went down.
Did a debug on the IP address of one of the extensions and got the following. Have crosschecked the passwords multiple times. Extension is setup with NAT.
From the remote office we can ping the freepbx server and from the server we can ping the device.

PBX Firmware:6.12.65-32
PBX Service Pack:1.0.0.0

<— Transmitting (NAT) to 192.168.2.198:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.198:5060;branch=z9hG4bKd3d959aa5d47b37f;received=192.168.2.198;rport=5060
From: “305” sip:[email protected];tag=8b737c0e182c4a8b
To: sip:[email protected];tag=as7dafe2bb
Call-ID: [email protected]
CSeq: 10001 REGISTER
Server: FPBX-13.0.192.18(13.9.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Expires: 0
Date: Wed, 18 Oct 2017 21:50:59 GMT
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘[email protected]’ in 32000 ms (Method: REGISTER)

<— SIP read from UDP:192.168.2.198:5060 —>
REGISTER sip:192.168.51.254 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.198:5060;branch=z9hG4bKd3d959aa5d47b37f
From: “305” sip:[email protected];tag=8b737c0e182c4a8b
To: sip:[email protected]
Contact: *
Supported: path
Call-ID: [email protected]
CSeq: 10001 REGISTER
Expires: 0
User-Agent: Grandstream GXP280 1.2.5.3
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Length: 0

<------------->
— (13 headers 0 lines) —
Sending to 192.168.2.198:5060 (NAT)

<— Transmitting (NAT) to 192.168.2.198:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.198:5060;branch=z9hG4bKd3d959aa5d47b37f;received=192.168.2.198;rport=5060
From: “305” sip:[email protected];tag=8b737c0e182c4a8b
To: sip:[email protected];tag=as7dafe2bb
Call-ID: [email protected]
CSeq: 10001 REGISTER
Server: FPBX-13.0.192.18(13.9.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Expires: 0
Date: Wed, 18 Oct 2017 21:51:03 GMT
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘[email protected]’ in 32000 ms (Method: REGISTER)
Packet timed out after 32000ms with no response

<— SIP read from UDP:192.168.2.198:5060 —>
REGISTER sip:192.168.51.254 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.198:5060;branch=z9hG4bK61fdaabd63862156
From: “305” sip:[email protected];tag=8b737c0e182c4a8b
To: sip:[email protected]
Contact: sip:[email protected]:5060;transport=udp
Supported: path
Call-ID: [email protected]
CSeq: 10001 REGISTER
Expires: 3600
User-Agent: Grandstream GXP280 1.2.5.3
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Length: 0

<------------->
— (13 headers 0 lines) —
Sending to 192.168.2.198:5060 (NAT)

<— Transmitting (NAT) to 192.168.2.198:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.198:5060;branch=z9hG4bK61fdaabd63862156;received=192.168.2.198;rport=5060
From: “305” sip:[email protected];tag=8b737c0e182c4a8b
To: sip:[email protected];tag=as7dafe2bb
Call-ID: [email protected]
CSeq: 10001 REGISTER
Server: FPBX-13.0.192.18(13.9.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="09e641ab"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘[email protected]’ in 32000 ms (Method: REGISTER)

<— SIP read from UDP:192.168.2.198:5060 —>
REGISTER sip:192.168.51.254 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.198:5060;branch=z9hG4bK61fdaabd63862156
From: “305” sip:[email protected];tag=8b737c0e182c4a8b
To: sip:[email protected]
Contact: sip:[email protected]:5060;transport=udp
Supported: path
Call-ID: [email protected]
CSeq: 10001 REGISTER
Expires: 3600
User-Agent: Grandstream GXP280 1.2.5.3
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Length: 0

cynjut · October 19, 2017, 3:47pm

Those two shouldn’t be used together. The VPN should be a local network, which means that the NAT shouldn’t be part of the equation.

Since ICMP traffic is getting passed, there’s got to be a problem with your port control configuration. Somewhere, somehow, the ports are getting blocked or incorrectly misdirected. Sounds like it’s time to review your router configuration.

hlusher · October 19, 2017, 4:30pm

There are no ports blocked on the router

cynjut · October 19, 2017, 6:34pm

Here’s my thought process:

Your phones were working.

You changed the network and router configuration.

Your phones don’t work.

Clearly is can’t be the router?

hlusher · October 19, 2017, 8:01pm

Whilst the physical router was changed… the configuration remains this same. Had I not mentioned that I had changed a router (which by not changing the config… i should not have mentioned)… based on the logs, what would have been the best method of tracking down the issue.

GSnover · October 19, 2017, 8:19pm

Before you waste any more time, establish some simple baselines:

From the PBX on the CLI, ping one of the remote phones through the VPN - If you can’t do this, it will NEVER work!
From the remote site, with a PC, ping the PBX on it’s internal IP.

Do these two things before you even begin troubleshooting the VoIP - It sounds to me like you don’t have connectivity between the sites.

Once you have done this, then start checking things like under SIP Settings you have the Local and Remote subnet listed as local subnets for Asterisk. Then make sure under the individual extensions that are going to be using the VPN that you have nat=no so no translation occurs.

Finally, check under System Admin - Intrusion detection and make sure both LAN segments are in the exclusion settings - Like so:

192.168.1.0/24
192.168.2.0/24

Substitute what you have, but you get the idea.

Greg

hlusher · October 19, 2017, 8:37pm

I believe I had mention that we can ping all devices. From the PBX we can ping the endpoint… from the remote site we can ping the PBX. Actually working from the PBX side and able to make changes to the endpoint via webgui.
Local and remote subnets are in place under SIP settings.
Have modified the extension setting to NO NAT as well.
Have also check the System Admin - Intrusion and that is correct.

GSnover · October 19, 2017, 8:44pm

ALL of those packets are coming from 192.168.2.198 - where is the other side?

hlusher · October 19, 2017, 8:46pm

Local network is 192.168.51.0/24 remote site is 192.168.2.0/24

GSnover · October 19, 2017, 8:51pm

That is what I am saying - you are not seeing any responses from the other side - and you should.

Have you tried a Packet Capture - It’s not very hard - Here:

https://www.tecmint.com/12-tcpdump-commands-a-network-sniffer-tool/

Grab a quick capture, look at it in WireShark and post the SIP Flow - It will show you if you are just talking to yourself (connectivity) or if you are talking to the endpoint and not sending (or receiving) what you expected.

hlusher · October 19, 2017, 9:34pm

Not really sure how much of a sample size you would need.

Speaker",“From”,“To”,“Protocol”,“Duration”,“Packets”,“State”,“Comments"
14.411440,“52.407359”,“192.168.2.199”,”“339” <sip:[email protected]","<sip:[email protected]",“SIP”,“00:00:37”,“16”,“REJECTED”,“REGISTER 401 401 401 401 401 401 401 401"
21.687200,“32.702026”,“192.168.2.198”,”“305” <sip:[email protected]","<sip:[email protected]",“SIP”,“00:00:11”,“10”,“REJECTED”,“REGISTER 401 401 401 401 401”

hlusher · October 19, 2017, 10:33pm

From the SIP traces… seems to me that the 3rd leg of the authentication process where the server sends a challenge to the endpoint is the issue… somehow the endpoint does not receive this challenge and keeps sending a register request. My problem though is if the endpoint sees the server , clearly there is communication between the 2 so why does the device not register.

GSnover · October 20, 2017, 3:22pm

Oooohhh - Lightbulb just went off in my head - I have had this problem before - I bet you are using Cisco switches/routers and I bet someone turned on Fragmented Packet Blocking - This was killing me with Polycom phones and even Cisco phones over a VPN - You have to ALLOW fragmented packets, especially with the Polycoms - symptoms were that you could not re-provision a Polycom (it would never download it’s provisioning) and it you re-booted a phone that was already provisioned you got messages like this - something to check.

corradomella · October 24, 2017, 8:35am

+1
SIP UDP traffic, especially during authentication, always comes in fragmented packets.
Check every router, switch, firewall.

hlusher · October 31, 2017, 4:59pm

problem was at the ISP provider…

GSnover · November 1, 2017, 7:07pm

Did they tell you what was wrong - if they did, you should add it to the post so if someone else has the problem, they will have an idea where to start.

hlusher · November 1, 2017, 7:09pm

They havent sorted the issue as yet so I cannot give an update… But i ran the connection via a separate ISP and was able to get all phones working.