Will Cisco 7961 phones work over a VPN with FreePBX

General Help
1

Just wondered if anyone had one of the Cisco 79x1 or 79x2 or similar phones working on FreePBX over a VPN
I have a working system locally with these phones but they wont register from over a VPN (a softphone works ok)
I suspect NAT issues, it seems these phones are picky over NAT

I have looked at the SIP registrations on the FPBX server and it is receiving a viable header and sending on out but I don’t think the phone is getting it, possibly due to the different subnet.
Any advise would be welcomed.

2

If you are using a different Subnet then you need to add it to the SIP settings.

Not sure how your setup is configures, but you also might need to Enable NAT on that Extension.

3

As long as the VPN, FreePBX firewall, FreePBX network settings and SIP settings are correctly configured, you should not have any issues at least regarding registration. NAT settings are very important for correct audio flow.

1 Like
4

Sorry for delay in replying. I’m having issues logging in to forum with original account I used to post and cannot recover it.

Thanks for the replies.

Everything is seemingly setup correctly if the soft phone works ok.

Registering the 7961s is the issue and I can see the registration request in the SIP debug from Asterisk. However, Asterisk seems to reply to the received address rather than the VIA address in the SIP header.
I can see the line;
<------------ Transmitting to 192.168.1.1 ------------>

Which is the routers IP the VPN is setup on.
The Asterisk server is at 192.168.1.39 and the phone is at 192.168.0.31

When the local phones register I see the transmit line has the correct phones IP but when the softphone connects from over the VPN the transmit line says the routers IP but it does register.

Could this be to do with rport not being supported on the Cisco 7961?

Very frustrating as it is so close to working.

5

Ok, it seems my forum login issues are resolved and I can now post again. All help appreciated.

6

Just to be clear the issue with the Cisco phones not registering is still not resolved, so if anyone knows why they wont register when a softphone does, then please let me know.

Thanks

7

There are so many reasons why these phones don’t work in SIP mode, it would probably be easier to talk about this things that do work. :slight_smile:

Experience item 1 - the password field in the phone is only about 10 characters long. This ultra wimpy password is just one of the many reasons I don’t recommend SIP and suggest sticking with SCCP.

The server’s /var/log/asterisk/full log should tell you a lot about the phone’s attempts to connect. Remember that the phone could be blacklisted in the local firewall, the configuration could be wrong, you could have a latent routing problem, there could be NAT issues, etc.

While SIP debug might seem like a good first step, you need to keep looking at the rest of your tools. The full logs, for example, will give you a lot of information. Your routing issues (192.168.1.x vs 192.168.0.x) might also be part of the problem. You could be running into a NAT issue as you traverse the network. There are just too many possibilities to do anything more than blindly hguess.

8

Thanks for the pointers, I will look at the full logs

In the mean time…
a Bit more info from the SIP DEBUG

<--------------------Transmitting (no NAT) to 192.168.1.1:5060 --------------------->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.31:5060;branch=z9hg4bk80e37e34;recieved=192.168.1.1

Background:
Hardware VPN
Server side Router at 192.168.1.1
Server at 192.168.1.38
Client side router 192.168.0.1
phone at 192.168.0.31

Phone works locally
Softphone works over the VPN as does the FPBX control panel and putty

9

Password problem. Gonna guess you have more than 8 characters in your password. That’s the common cause.

This password limitation is one of the reasons I don’t use Cisco phones in SIP mode.

10

Thanks for the suggestion I will alter the password and try again. However, it is strange because I took a phone that has been working in the office for a year or more and just moved it to the remote site for testing. I haven’t altered the username or password.
I agree that these handsets are not easy to work with. I believe that the Cisco SPA models are much better.

11

They work fine in SCCP mode - my customers and I love them for desk phones in the local network; I’ve installed hundreds of them. As SIP phones, through, they are terrible. The firmware for SIP requires more “horsepower” than the phone’s CPU can usually muster. The SIP password limitation alone makes them unsuitable for anything of any real usefulness. Since the SCCP mode phones don’t use passwords (the authenticate using a different method) they don’t open the system up to more immediate hack attacks.

12

I didn’t realise you could use them without a licienced call manager in SCCP
Whilst I have been using 20 of these as local SIP phones without major incident for a few years, I do agree that there are better phones out there. However, now I need to operate them over the established and secure VPN and can’t. I might purchase an SPA type cisco phone and try that.

13

Ok, I have been looking at the asterisk full log and I cant really see any more information than is given with the SIP debug. Am I missing something?

Here is the log…
<— SIP read from UDP:192.168.1.1:49195 —>
REGISTER sip:192.168.1.38 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.31:5060;branch=z9hG4bKf1019337
From: <sip: [email protected] 8.1.38>;tag=001818b990b70002714c41f4-aa4ef319
To: <sip:[email protected]. 1.38>
Call-ID: 001818b9-90b [email protected]
Max-Forward s: 70
Date: Wed, 16 Dec 200 9 08:09:16 GMT
CSeq: 101 REGISTER
User-Agent: Cisco-CP7 961G/8.5.3
Contact: sip:[email protected]:5060;transport=udp;+sip.instance=“urn:uuid:00000000-0000-0000-0000-001818b990b7”;+u.sip!model.ccm.cisco.com="30018"
Supported: (null),X-cisco-xsi-7.0.1
Content-Length: 0
Reason: SIP ;cause=200 ;text="cisco-alarm:20 Name=SEP001818B990B7 Load=SIP41.8-5-4S Last=phone-keypad"
Expires: 36 0

<------------->
[2017-09-12 21:16:28] VERBOSE[12939] chan_sip.c: — (14 headers 0 lines) —
[2017-09-12 21:16:28] VERBOSE[12939] chan_sip.c: Sending to 192.168.1.1:5060 (no NAT)
[2017-09-12 21:16:28] VERBOSE[12939] chan_sip.c:
<— Transmitting (no NAT) to 192.168.1.1:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.31:5060;branch=z9hG4bKf1019337;received=192.168.1.1
From: <sip: [email protected]>;tag=001818b990b70002714c41f4-aa4ef319
To: sip:[email protected];tag=as47331078
Call-ID: 00 [email protected]
CSeq: 101 REGISTER
Server: FPB X-13.0.192 .16(13.7.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="59922dd5"
Content-Length: 0

<------------>
[2017-09-12 21:16:28] VERBOSE[12939] chan_sip.c: Scheduling destruction of SIP dialog ‘[email protected]’ in 32000 ms (Method: REGISTER)
[2017-09-12 21:16:32] VERBOSE[12939] chan_sip.c:
<— SIP read from UDP:192.168.1.1:49196 —>
REGISTER sip:192.168. 1.38 SIP/2.0
Via: SIP/2. 0/UDP 192. 168.0.31:5060;branch=z9hG4bKf1019337
From: <sip: [email protected] 8.1.38>;tag=001818b990b70002714c41f4-aa4ef319
To: <sip:[email protected]. 1.38>
Call-ID: 00 1818b9-90b [email protected]
Max-Forward s: 70
Date: Wed, 16 Dec 200 9 08:09:16 GMT
CSeq: 101 REGISTER
User-Agent: Cisco-CP7 961G/8.5.3
Contact: <s ip:204@192 .168.0.31:5060;transport=udp>;+sip.instance=“urn:uuid:00000000-0000-0000-0000-001818b990b7”;+u.sip!model.ccm.cisco.com="30018"
Supported: (null),X-c isco-xsi-7.0.1
Content-Len gth: 0
Reason: SIP ;cause=200 ;text="cisco-alarm:20 Name=SEP001818B990B7 Load=SIP41.8-5-4S Last=phone-keypad"
Expires: 36 0

<------------>
[2017-09-12 21:16:32] VERBOSE[12939] chan_sip.c: — (14 headers 0 lines) —
[2017-09-12 21:16:32] VERBOSE[12939] chan_sip.c: Sending to 192.168.1.1:5060 (no NAT)
[2017-09-12 21:16:32] VERBOSE[12939] chan_sip.c:
<— Transmitting (no NAT) to 192.168.1.1:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2. 0/UDP 192. 168.0.31:5060;branch=z9hG4bKf1019337;received=192.168.1.1
From: <sip: [email protected] 8.1.38>;tag=001818b990b70002714c41f4-aa4ef319
To: <sip:20 [email protected]. 1.38>;tag=as47331078
Call-ID: 00 1818b9-90b [email protected]
CSeq: 101 REGISTER
Server: FPBX-13.0.192 .16(13.7.1)
Allow: INVITE, ACK, C ANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="59922dd5"
Content-Length: 0

14

The Cisco 79xx phones require licensing whether you use SCCP or SIP.

15

OK, I see that SCCP can be added to Asterisk. Probably what I should have done at the start. However, I really don’t fancy upsetting a fully working system and re programming 20 handsets.
If anyone can point me in the right direction as to why the SIP 7961 wont register over a VPN then I would very much appreciate it. (registration attempt from the log file is above)

16

Your logs are garbled due to interpreting of HTML tags. Please post them in a code block or use pastebin.

17

Here is the log..... <--- SIP read from UDP:192.168.1.1:49195 ---> REGISTER sip:192.168.1.38 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.31:5060;branch=z9hG4bKf1019337 From: ;tag=001818b990b70002714c41f4-aa4ef319 To: Call-ID: 001818b9-90b [email protected] Max-Forward s: 70 Date: Wed, 16 Dec 200 9 08:09:16 GMT CSeq: 101 REGISTER User-Agent: Cisco-CP7 961G/8.5.3 Contact: ;+sip.instance="";+u.sip!model.ccm.cisco.com="30018" Supported: (null),X-cisco-xsi-7.0.1 Content-Length: 0 Reason: SIP ;cause=200 ;text="cisco-alarm:20 Name=SEP001818B990B7 Load=SIP41.8-5-4S Last=phone-keypad" Expires: 36 0 <-------------> [2017-09-12 21:16:28] VERBOSE[12939] chan_sip.c: --- (14 headers 0 lines) --- [2017-09-12 21:16:28] VERBOSE[12939] chan_sip.c: Sending to 192.168.1.1:5060 (no NAT) [2017-09-12 21:16:28] VERBOSE[12939] chan_sip.c: <--- Transmitting (no NAT) to 192.168.1.1:5060 ---> SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.0.31:5060;branch=z9hG4bKf1019337;received=192.168.1.1 From: ;tag=001818b990b70002714c41f4-aa4ef319 To: ;tag=as47331078 Call-ID: 00 [email protected] CSeq: 101 REGISTER Server: FPB X-13.0.192 .16(13.7.1) Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="59922dd5" Content-Length: 0 <------------> [2017-09-12 21:16:28] VERBOSE[12939] chan_sip.c: Scheduling destruction of SIP dialog '[email protected]' in 32000 ms (Method: REGISTER) [2017-09-12 21:16:32] VERBOSE[12939] chan_sip.c: <--- SIP read from UDP:192.168.1.1:49196 ---> REGISTER sip:192.168. 1.38 SIP/2.0 Via: SIP/2. 0/UDP 192. 168.0.31:5060;branch=z9hG4bKf1019337 From: ;tag=001818b990b70002714c41f4-aa4ef319 To: Call-ID: 00 1818b9-90b [email protected] Max-Forward s: 70 Date: Wed, 16 Dec 200 9 08:09:16 GMT CSeq: 101 REGISTER User-Agent: Cisco-CP7 961G/8.5.3 Contact: ;+sip.instance="";+u.sip!model.ccm.cisco.com="30018" Supported: (null),X-c isco-xsi-7.0.1 Content-Len gth: 0 Reason: SIP ;cause=200 ;text="cisco-alarm:20 Name=SEP001818B990B7 Load=SIP41.8-5-4S Last=phone-keypad" Expires: 36 0 <------------> [2017-09-12 21:16:32] VERBOSE[12939] chan_sip.c: --- (14 headers 0 lines) --- [2017-09-12 21:16:32] VERBOSE[12939] chan_sip.c: Sending to 192.168.1.1:5060 (no NAT) [2017-09-12 21:16:32] VERBOSE[12939] chan_sip.c: <--- Transmitting (no NAT) to 192.168.1.1:5060 ---> SIP/2.0 401 Unauthorized Via: SIP/2. 0/UDP 192. 168.0.31:5060;branch=z9hG4bKf1019337;received=192.168.1.1 From: ;tag=001818b990b70002714c41f4-aa4ef319 To: ;tag=as47331078 Call-ID: 00 1818b9-90b [email protected] CSeq: 101 REGISTER Server: FPBX-13.0.192 .16(13.7.1) Allow: INVITE, ACK, C ANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="59922dd5" Content-Length: 0

18

is that better?
They both look OK on my end

19

Unfortunately no - it’s still eating the sip: tags

From: ;tag=001818b990b70002714c41f4-aa4ef319
To:
Contact: ;+sip.instance="";+u.sip!model.ccm.cisco.com=“30018”

20

The register attempt