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
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
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?
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
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)
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
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)
Quazar,
Can you go into CLI and do a show run user 303 and send me output.
-Mark
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
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
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.
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
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
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)
You said in previous post that you have turned off SIP helpers. Have you tested it with the SIP helpers on?
-Mark
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.
What do you mean generic accounts vs specific accounts?
-Mark
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.
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