Simple remote user won't register with 7100

[Anonymous]

Hi,

I have a a few remote users that are connected and working with my 7100. One user however is giving me fits.  When I run a debug  using debug sip user-registration (ext)  I keep getting the following error...

SIP.USER-REG 124 Registration rejected with authentication challenge (Unauthorized)

I have tried creating a new SIP auth password in the CLI, and the rebooted the phone, but still no luck.

Any help is appreciated!

Thanks,

Matt

[Anonymous]

You need to reset the password via the GUI. When you go to the user in gui and reset the password it updates the user and the phone config file. When you do it from the CLI, it only updates the user in the running-config and the phone config file never gets updated.

Let me know if you need to know how to edit via the GUI.

-Mark

[Anonymous]

Thanks for the response Mark! I'm sorry but I meant to say that I changed it in the GUI, not the CLI.  Its only the SIP Auth password that I need to regenerate correct? I've done this a few times and had him reboot his phone with no luck. The unfortunate thing is that hes in CA and I'm in NY so I cant just have him send it back. Any thing else I can check?

[Anonymous]

Did you manually program the phone with the 7100’s information in it?

Can you do a debug ip ftp-sever to verify that the phone is downloading the new config file and not just using the old one?

-Mark

[Anonymous]

Yes I manually input the FTP server IP address along with the username and password

Unfortunately the debug ip ftp-server didn't provide any feedback except what I pasted below. Do you think maybe the failed authentication is because I have an incorrect username or password for the FTP server?

7100#sh deb

debug ip ftp-server

debug sip user-registration 124

7100#

12:09:36.999 SIP.USER-REG 124 Registration rejected with authentication challenge (Unauthorized)

12:09:37.188 SIP.USER-REG 124 Registration rejected with authentication challenge (Unauthorized)

12:09:37.386 SIP.USER-REG 124 Registration rejected with authentication challenge (Unauthorized)

[Anonymous]

If you don’t see any debug from the ftp-server command, then the phone is not downloading the new config file with the new authentication password. You might want to walk the user through the phone menus and make sure it has the right information in it. Or you could try manually setting the auth password from phone. Also go to voice > reports > sip security and make sure the phone is not in black list.

-Mark

[Anonymous]

I am also having the same issue with a 712 at a remote site.  I have deleted and re-created the phone from scratch,  I verified that it does download the config files from the FTP server.  I also connected the the HTTP interface on the phone and was able to see the simple SIP Auth Password that I had set via the GUI.  I tried power cycling the phone and also re-setting to factory with no difference:

10:29:10.131 SIP.USER-REG 303 Registration rejected with authentication challenge (Unauthorized)

10:29:10.625 SIP.USER-REG 303 Registration rejected with authentication challenge (Unauthorized)

10:29:11.628 SIP.USER-REG 303 Registration rejected with authentication challenge (Unauthorized)

[Anonymous]

Quazar,

Can you go into CLI and do a show run user 303 and send me output.

-Mark

[Anonymous]

Quazar,

After further looking at your “Buffalo_SIP_Stack.txt” debug of your phone register, it looks like your 303 phone keeps registering unauthenticated and never authenticates. If you look at the debug you see the 7100 receive the Register. It has a CSeq of 1333510926, then the 7100 TX a 401 Unauthorized which is normal. It contains the WWW-Authenticate header containing the nonce which is supposed to be used in the following Register. If you look at the next Rx register at time stamp 10:10:39.099 the CSeq did not change. In normal registration, the 401 Unregistered should have terminated the original Register transaction, so the phone sends a new invite with same call-id with a Authentication header and increments the CSeq value, but if you look, the Cseq never changes. Also none of the registers contain the Authentication field.

What the problem is that the Router/Firewall device at the remote site is preventing the 401 Unauthorized from reaching the phone. The phone never sees the 401 Unauthorized packet so it just keeps trying to register unauthenticated. Please check your router at the remote site. What type of device is it? Are there more remote phones at that site? To prove this you could port mirror the switch port the phone is plugged into and mirror it out another port to a laptop or computer and run Wireshark and do a packet capture. That would easily prove this.

Here is what a correct registration dialogue looks like, notice the CSeq increment in the 2nd invite and how the 2nd invite contains the Authentication header:

12:35:27.713 SIP.STACK MSG Tx: UDP src=216.206.86.15:5060 dst=216.206.86.124:5060

12:35:27.713 SIP.STACK MSG REGISTER sip:216.206.86.124:5060 SIP/2.0

12:35:27.713 SIP.STACK MSG From: <sip:2568816515@216.206.86.15:5060;transport=UDP>;tag=564f820-7f000001-13c4-1904e-8701d9ec-1904e

12:35:27.713 SIP.STACK MSG To: <sip:2568816515@216.206.86.124:5060;transport=UDP>

12:35:27.714 SIP.STACK MSG Call-ID: 57374d0-7f000001-13c4-ae-cceb8162-ae

12:35:27.714 SIP.STACK MSG CSeq: 65 REGISTER

12:35:27.714 SIP.STACK MSG Via: SIP/2.0/UDP 216.206.86.15:5060;branch=z9hG4bK-1904e-61bb183-4b5ee977

12:35:27.714 SIP.STACK MSG Max-Forwards: 70

12:35:27.714 SIP.STACK MSG Supported: 100rel,replaces

12:35:27.714 SIP.STACK MSG Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER

12:35:27.715 SIP.STACK MSG User-Agent: ADTRAN_NetVanta_7100/R11.10.1.E

12:35:27.715 SIP.STACK MSG Contact: <sip:2568816515@216.206.86.15:5060;transport=UDP>

12:35:27.715 SIP.STACK MSG Expires: 3600

12:35:27.715 SIP.STACK MSG Content-Length: 0

12:35:27.715 SIP.STACK MSG

12:35:27.722 SIP.STACK MSG Rx: UDP src=216.206.86.124:5060 dst=216.206.86.15:5060

12:35:27.722 SIP.STACK MSG SIP/2.0 401 Unauthorized

12:35:27.722 SIP.STACK MSG From: <sip:2568816515@216.206.86.15:5060;transport=UDP>;tag=564f820-7f000001-13c4-1904e-8701d9ec-1904e

12:35:27.722 SIP.STACK MSG To: <sip:2568816515@216.206.86.124:5060>;tag=526f970-a0a0a01-13c4-19056-95b568cb-19056

12:35:27.722 SIP.STACK MSG Call-ID: 57374d0-7f000001-13c4-ae-cceb8162-ae

12:35:27.723 SIP.STACK MSG CSeq: 65 REGISTER

12:35:27.723 SIP.STACK MSG WWW-Authenticate: Digest realm="216.206.86.124",nonce="526f9703e81a"

12:35:27.723 SIP.STACK MSG Via: SIP/2.0/UDP 216.206.86.15:5060;branch=z9hG4bK-1904e-61bb183-4b5ee977

12:35:27.723 SIP.STACK MSG Supported: 100rel,replaces

12:35:27.723 SIP.STACK MSG Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER

12:35:27.724 SIP.STACK MSG User-Agent: ADTRAN_NetVanta_7100/A5.03.00.E

12:35:27.724 SIP.STACK MSG Content-Length: 0

12:35:27.724 SIP.STACK MSG

12:35:27.727 SIP.STACK MSG Tx: UDP src=216.206.86.15:5060 dst=216.206.86.124:5060

12:35:27.727 SIP.STACK MSG REGISTER sip:216.206.86.124:5060 SIP/2.0

12:35:27.728 SIP.STACK MSG From: <sip:2568816515@216.206.86.15:5060;transport=UDP>;tag=564f820-7f000001-13c4-1904e-8701d9ec-1904e

12:35:27.728 SIP.STACK MSG To: <sip:2568816515@216.206.86.124:5060;transport=UDP>

12:35:27.728 SIP.STACK MSG Call-ID: 57374d0-7f000001-13c4-ae-cceb8162-ae

12:35:27.728 SIP.STACK MSG CSeq: 66 REGISTER

12:35:27.729 SIP.STACK MSG Via: SIP/2.0/UDP 216.206.86.15:5060;branch=z9hG4bK-1904e-61bb191-50a945c7

12:35:27.729 SIP.STACK MSG Max-Forwards: 70

12:35:27.729 SIP.STACK MSG Supported: 100rel,replaces

12:35:27.729 SIP.STACK MSG Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER

12:35:27.729 SIP.STACK MSG User-Agent: ADTRAN_NetVanta_7100/R11.10.1.E

12:35:27.730 SIP.STACK MSG Contact: <sip:2568816515@216.206.86.15:5060;transport=UDP>

12:35:27.730 SIP.STACK MSG Expires: 3600

12:35:27.730 SIP.STACK MSG Authorization: Digest username="2568816515",realm="216.206.86.124",nonce="526f9703e81a",uri="sip:216.206.86.124:5060",response="8312198d872a76aebd18785abbc09b43",algorithm=MD5

12:35:27.730 SIP.STACK MSG Content-Length: 0

12:35:27.730 SIP.STACK MSG

12:35:27.738 SIP.STACK MSG Rx: UDP src=216.206.86.124:5060 dst=216.206.86.15:5060

12:35:27.738 SIP.STACK MSG SIP/2.0 200 OK

12:35:27.738 SIP.STACK MSG From: <sip:2568816515@216.206.86.15:5060;transport=UDP>;tag=564f820-7f000001-13c4-1904e-8701d9ec-1904e

12:35:27.738 SIP.STACK MSG To: <sip:2568816515@216.206.86.124:5060>;tag=5272fb0-a0a0a01-13c4-19056-8d2263aa-19056

12:35:27.739 SIP.STACK MSG Call-ID: 57374d0-7f000001-13c4-ae-cceb8162-ae

12:35:27.739 SIP.STACK MSG CSeq: 66 REGISTER

12:35:27.739 SIP.STACK MSG Contact: <sip:2568816515@216.206.86.15:5060;transport=UDP>

12:35:27.740 SIP.STACK MSG Expires: 3600

12:35:27.740 SIP.STACK MSG Via: SIP/2.0/UDP 216.206.86.15:5060;branch=z9hG4bK-1904e-61bb191-50a945c7

12:35:27.740 SIP.STACK MSG Supported: 100rel,replaces

12:35:27.740 SIP.STACK MSG Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER

12:35:27.740 SIP.STACK MSG User-Agent: ADTRAN_NetVanta_7100/A5.03.00.E

12:35:27.741 SIP.STACK MSG Content-Length: 0

Let me know if you have any questions.

-Mark

[Anonymous]

Nettech_NV7100#sh run voice user 303

Building configuration...

!

!

!

voice user 303

  connect sip

  cos "normal_users"

  no cos night

  no cos lunch

  no cos weekend

  no cos override

  no cos custom1

  no cos custom2

  no cos custom3

  first-name "Scott"

  last-name "Emser"

  password encrypted "3135e1c931c57f186b963c832c6893169202"

  group-ring-call-waiting

  coverage  vm 303

  sip-authentication password encrypted "343292ec99d7a75db286649962d193cb80ee"

  codec-list g711_first both

  email semser@net-cloud.com

  voicemail cos normal_voicemail

  voicemail password encrypted "191d6d2607a0b620443811b254d8f6fb7ecb"

  voicemail notify schedule Sunday 12:00 am

!

!

end

[Anonymous]

Mark,

I'll try to get to get a capture as soon as I can.  The VPN to the remote site is wide open and I had this 712 and a Polycom 650 connected with generic extension at one point, but when I tried to assign a user to the phone, the phone refusing to register.

[Anonymous]

Well something is blocking the return of the 401 Unauthorized to the 712 phone. Just need to figure out where.

What device is the VPN gateway at the remote site? You can do a packet capture in AOS now if your running newer code.

Are you running GRE through the VPN tunnel?

-Mark

[Anonymous]

Mark,

Not running GRE.  The Fortigate Firewall at the remote end has a wide open tunnel and I turned off any SIP helpers.  Here is a packet capture from the inside interface of the firewall.

[Anonymous]

Ok after looking over your debug and getting some good insight from Jay in support, it looks like your Fortigate is not changing the port on the return 401.

Here is the run down from your pcapture and the buffalo_SIP_Stack.txt file. Different calls but the ports are what we are looking at:

Wireshark Packet 1:

Register from phone before the Fortigate.

Source IP is 192.168.129.57 (phone) on UDP port 5060 (phone is listening for port 5060)

Dest IP is 192.168.108.2 (7100) on udp port 5060

From 7100 Debug:

7100 RX register request

Source IP: 192.168.129:57 Your Fortigate changes the port to 10254 in that call

Destination IP: 192.168.108.2 port 5060

From 7100 Debug:

7100 TX 401 Unath back to phone

Source IP: 192.168.108.2 port 5060

Destination IP: 192.168.129.57 port 10254 (We transmit the same port we received)

Wireshark Packet 2:

401 Unath from 7100 after the Fortigate

Source IP: 192.168.108.2 port 5060

Destination IP: 192.168.129.57 port 10004 (this is actual port from this call) But the problem is that Fortigate is not changing the port back after it is NATing it.

The phone is listening on port 5060, but the return 401 Unauthorized is coming back on the 10000 port range so the phone is not listening for that port and just keep registering. You need to look into the Fortigate and see if you can turn of NAT of SIP packets or have it properly change the port back to 5060 on the return path.

Let us know if you have any other questions.

-Mark

[Anonymous]

Mark,

I will have to look into the firewalls at both ends (Check Point & Fortigate), but NAT is turned off at both ends.  I will let you know what I find (if anything)

[Anonymous]

You said in previous post that you have turned off SIP helpers. Have you tested it with the SIP helpers on?

-Mark

[Anonymous]

Mark,

Actually, when I went back into the remote firewall, the SIP helper had been turned back on, so I went through the process to turn it back off, but still no luck.  What I have to do at this point is setup some simultaneous captures from both ends and try to determine which firewall is changing the packet.  The frustrating part is that I had the phones setup and working with generic accounts, but when I tried to change them to specific users, that is when they broke.

[Anonymous]

What do you mean generic accounts vs specific accounts?

-Mark

[Anonymous]

Mark,

By generic accounts, I mean that I had 2 user accounts with no voice mail, or call control...ie Buffalo Phone 1 & 2.  Not sure how I had them working.  Spent 4 hours on Friday doing packet captures at both ends of the tunnel and then opening tickets with both firewall vendors.  Right now both vendors are claiming that they are not modifying the packet, but according to the packet captures, somebody is.  Now have to get one of them to figure out who is doing it and fix it.

[Anonymous]

Thanks for the update. Not sure how they can argue against a packet capture. Can’t get more raw info than that.

Solution 3: put ADTRAN router/firewall/VPN at edge 😃

-Mark