We got a couple of refurbished Cisco 7961G phones that I wanted to use as SIP phones with an Asterisk server. If I knew it would be so hard, I would have thrown them away and bought some decent SIP phones. However, I did not know it would be hard, and I hate to give up 🙂

Just as a reference I wanted to share the config I used, and the problems I ran into.

First, the Cisco 7961G phones do not support SIP by default. They only speak SCCP, which we do not use with Asterisk. I downloaded the SIP version of the firmware with Cisco (cmterm-7941_7961-sip.8-0-4SR1.zip). I think you can also find this version somewhere on the internet. Be careful not to upgrade to the highest version in one go. You can only upgrade one version at a time. So don’t upgrade to the latest version. Take a loot at the following URL, as not all firmware versions are free of bugs…
Voip-info on 7961G

Second, when I got the firmware loaded, after I bricked the phone a couple of times, I could start the config. I have some 7960’s and they work with simple text config files. The 7961G use XML config. If there is a config error the config will not load an the phone is unprovisioned. Also I did not find a way to change the config on the phone menu itself. I’ve pasted the XML config below. Be sure to change it for your environment.

Thirdly, I had to configure the sip user in Asterisk. The phone does not support NAT and qualify. I’ve pasted the config below as well.

Last but not least… the phone does not support NAT. Where our old 7960’s work fine over NAT, this phone only accepts SIP traffic back on port 5060 which by default makes it impossible (or unmanagable) to have multiple phones behind NAT. I have configured a VPN tunnel between our Asterisk server and the location where the phones are.

I hope this helps someone save some time on configuring the 7961G for SIP with Asterisk 🙂

XML config file (SEPXXXXXXXXXXXX.cnf.xml):


<timeZone>Eastern Standard/Daylight Time</timeZone>
<member priority=”0″>
<line button=”1″>
<line button=”2″>

asterisk config:

username = 100
transfer = yes
mailbox = 100
call-limit = 100
fullname = Username
registersip = no
callgroup = 1
context = employees
cid_number = 100
hasvoicemail = no
vmsecret =
email =
threewaycalling = yes
hasdirectory = no
callwaiting = yes
hasmanager = no
hasagent = yes
hassip = yes
hasiax = yes
secret = password
canreinvite = no
dtmfmode = rfc2833
insecure = no
pickupgroup = 1
autoprov = no
label =
macaddress =
linenumber = 1
disallow = all
allow = g729,alaw,ulaw,gsm


Since the Cisco VPN client does not work under OSX Lion anymore there was no easy way to connect with certificate authentication. It took some time but I managed to get it working under Lion with the build in VPN Client. Find the steps below to get the certificates imported and working with the VPN Client.

  • Create key: openssl genrsa -des3 -out vpn-cert2.key 1024
  • Create CSR (make sure that the CN is a simple name, no spaces or special characters): openssl req -new -key vpn-cert2.key -out vpn-cert2.csr
  • Request certificate with your CA
  • Create a p12 file from the key and the certificate: openssl pkcs12 -export -inkey vpn-cert2.key -in certnew-3.cer -out vpn.p12
  • Import the p12 file (containing the key and certificate) in the system keychain (not the login keychain, that doesn’t work): sudo security import vpn.p12 -k /Library/Keychains/System.keychain
  • If needed you can import the CA in your keychain and trust the imported certificate: sudo security add-trusted-cert -k /Library/Keychains/System.keychain root.ca.pem
    Note:Make sure that if you import your own CA, that you do it this way. Otherwise the VPN server certificate will not be verified correctly.

To use the certificate for VPN authentication do the following:

  • Open System Preferences
  • Go to Network
  • Click + to add network interface, Select Interface: VPN, VPN Type: Cisco IPSec
  • Click Create
  • In the Server Address type the hostname of the firewall. This is really important. The firewall has a certificate configured on the FQDN. Make sure the server address is the name of the certificate in the firewall. This FQDN can be found in the trustpoint configuration (see below)
  • Enter the username
  • Click Authentication Settings
  • Select Certificate and Click Select
  • Select the correct certificate that you just imported
  • Click OK
  • Click Apply

When you are not able to select the certificate you created the problem is that the CN is not supported. Make sure the CN that you used to create the CSR does not contain spaces or special characters.

Firewall trustpoint config:

crypto ca trustpoint CA1
enrollment terminal
fqdn fw.xxxx.com
subject-name CN=fw.xxxx.com,OU=IT,O=XXX Limited,C=NL,St=NH,L=Amsterdam

Tacacs is a great way to centralize user authentication, authorization and accounting. While tacacs originally is a Cisco thing, there is an open source server version available, tac_plus (http://www.gazi.edu.tr/tacacs/index.php?page=download). Installing the tacacs server is quite straight forward. Configuring the switch is not difficult either, as long as you think about possible failures. You don’t want to be locked out of your switches when your tacacs server is not available. I use the following configuration that uses two tacacs servers and asks for the enable password when neither of the tacacs servers is available. To enter ‘enable’ mode, the configured enable password suffices. Use the following Cisco configuration for a save AAA authentication.

NOTE: Always be careful when changing authentication and authorization configuration, as this might lock you out of the device. The savest way is to do this on the console of the machine.

aaa new-model
aaa authentication login default group tacacs+ enable
aaa authentication enable default enable
aaa authorization exec default group tacacs+ if-authenticated
aaa authorization commands 15 default group tacacs+ if-authenticated
aaa authorization network default group tacacs+ if-authenticated
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
aaa accounting system default start-stop group tacacs+
aaa session-id common
tacacs-server host single-connection
tacacs-server host single-connection
tacacs-server key TACACSKEY
tacacs-server directed-request

To restrict access to specific devices, you can configure an ACL in the tacacs configuration on the server (tac_plus.conf). See the example below.

user = username {
login = des "XXXX"
member = admin
acl = mgmt_devices
service = shell {
priv-lvl = 15
group = admin {
default service = permit
service = exec {
priv-lvl = 15
# acl's

acl = mgmt_devices {
permit =
permit =

Due to the shortage of IPv4 IP addresses, we will run out of IPv4 some day in the near future (approx. 699 days from now, http://inetcore.com/project/ipv4ec/index_en.html). To be prepared for this we are experimenting with IPv6. We got a /32 allocated by RIPE, and are currently preparing a live network to connect some services via native  IPv6 to the internet. While reviewing the IPv6 capabilities of the network equipment we use, I found out that Cisco ASA/Pix does not support failover when running IPv6. For details on this matter please see the following links:

  • http://www.v4tov6.com/2009/06/cisco-asa-ipv6-failover-update.html
  • http://v4tov6.com/2008/11/cisco-asa-ipv6-failover.html
  • http://forums.cabling-design.com/cisco/Re-PIX-IPv6-Failover-bug-4167-.htm

This failover support seems to be lacking for some time now, and is still missing in the latest release. I’ve notified our sales rep. at Cisco about this. Personally I think this is quite a serious issue, as failover is a essential part of building serious infrastructures. I hope Cisco will see that this feature should be implemented as soon as possible.

If you consider this a serious issue as well, I recommend you notify your Cisco contact. Also leave a comment, just because I’m wondering how many people think this is a problem 🙂

06 april 2010: Cisco released ASA version 8.3 which solves this problem: http://www.networkworld.com/community/node/58537

When using rancid you have to store the username and password in a text file. When you don’t want to give the user privilege level 15 you have to store the enable password as well. Tacacs with authorization is the best solution to restrict access for the rancid user. Since the rancid user doesn’t need to change any configuration on the network devices, you can restrict the commands it is allowed to run.

When using tac_plus (http://www.shrubbery.net/tac_plus/) you can use the following definition for the rancid user:

user = rancid {
#    default service = permit
login = cleartext "XXX"
enable = cleartext "XXX"
name = "Rancid User"
service = exec {
priv-lvl = 15
cmd = show {
permit .*
cmd = write {
permit term
cmd = dir {
permit .*
cmd = admin {
permit .*
cmd = more {
permit .*


user = rancid {
#    default service = permit
login = cleartext “R4nc!d”
enable = cleartext “raNc1d_3naB1e”
name = “Rancid User”
service = exec {
priv-lvl = 15
cmd = show {
permit .*
cmd = write {
permit term
cmd = dir {
permit .*
cmd = admin {
permit .*

The rancid user is automatically in enable mode because the privilege level is set to 15 in tacacs. You have to configure rancid no to enter enable mode. This is configured (for cisco devices) in ~rancid/.cloginrc

Enter the following details:

add user        *       rancid
add password    *       XXX
add method      *       telnet
add autoenable  *       1