EDITORS NOTE: I removed this post’s images because new firmware doesn’t match.  This article is older (originally written in 2010), but may still be useful to some people. I will be updating this article with more relevant information.

This article will answer that technical question, but first, I must tell my OOMA story – for those of my friends that don’t know it (for those who want to skip right to the technical goodness – aim for the bold titled section, skipping 3 paragraphs):

It has been well over a year now since I gave up my Vonage account in favor of an OOMA device (www.ooma.com).  Since the switch, I have paid very, very little for telephone service:  the cost of the device, the cost of their premier annual service subscription, and less than 20 cents for calls to Canada.

The annual service subscription is optional but at $119.99/year gives:   access to an instant second line, three-way conferencing, multi-ring (ring my phone and the my mobile at the same time), lets me screen calls as they are leaving voicemail (just like an old answering machine attached to a line – but the recording side is at OOMA’s voicemail accessible online or from the device while the audio is played for me to screen), forwards voicemails as email attachments, anonymous call reject, community blacklists (which I send to voicemail) and a personal blacklist, call forwarding, a custom ring for my 2nd line… etc.  the list does go on.  So, I spend about $120/year on my house phone service in total after buying the OOMA device.  I originally paid about $250.00 for my device.  As an early adopter, I had the OOMA hub and then out came the new and improved OOMA Telo.  I drooled and paid a trade up fee.  While Vonage was costing me in hardware and service, about $600/year – I got my first year and a half on OOMA at about $470.00 in total – and I got way more features for that price.  I like getting a good deal for a cool thing – and that is what I feel I got with OOMA.

Over the last few months, I have been slowly watching as the phone batteries in my ATT multiple handset device – plugged into my OOMA – started to loose their battery life.  Such is life and I could just replace the rechargeable Ni-Cad batteries.  However, I also had seen that OOMA released the OOMA Telo + Handset upgrade offering for existing OOMA hub owners.  So, I decided to upgrade to the new device, which was purported to have better call quality, some really cool blue-tooth integration (like the ability to transfer calls to a headset).  So, I bought, and had a defective OMAA handset (the #2 button would not register when pressed).  OMAA replaced the handset for me – sending me a new one – having me send the failed one back.  But then I found a problem.  The old handset was registered still as handset 1 and my new one as handset 2.  Technically, this worked just fine – but I wondered what would happen when I decided to replace my other failing ATT phones with more OOMA Telo handsets.  The OOMA Telo can have up to 4 handset (and with the Bluetooth adapter can pair up to 7 headsets!  So, I called OOMA support and they gave me the setup command below to fix the problem.  Ultimately their solution worked and I am happy with my OOMA Telo and look forward to testing it with my Bose QC3 Bluetooth adapter, my Plantronics Bluetooth headset, and my T-MOBILE HTC Touch Pro 2 cell phone.  Now onto the real technical stuff.

Accessing the OOMA setup page without using the Home Port

According to the OOMA telephone support representative, I need to access setup.ooma.com from a computer attached to my OOMA Telo’s Home Port.  Depending upon how the OOMA device is deployed in the network – this can be very inconvenient.  OMAA seems to prefer customers setup their device so that it fits the following network design:

Option 1:  Internet –> Modem –> OMAA –> Router

NOTE:  OOMA device’s “Internet” port is attached to modem and “Home” port is attached to the router’s WAN/Internet interface.

This method allows the OMAA device to not have deal with router settings.  To OMAA’s credit, that is not really bad thinking because there are a lot of router vendors out there and many routers do not perform well.  OOMA wants their device to do the Quality of Service needed to make sure your voice packets are given the highest priority.  However, many IT people, avid gamers, XBOX players, small business owners, etc. may find the following configuration more useful for controlling their network:

Option 2:  Internet –> Modem –> Router –> OMAA

NOTE:  OOMA device’s “Internet” port is attached to the router just like any other PC on the network.  Nothing is attached to the OOMA device’s “Home” port.

This 2nd option requires configuring your router to handle and Quality of Service but also means you don’t have deal with OOMA as a port forwarding device, etc., when setting up other things on the network such as XBOX 360’s access to XBOX Live.  Although this configuration requires more knowledge of how to configure the router, it is probably preferable since many routers support Universal Plug and Play allowing devices, like the XBOX 360, and PCs, to dynamically tell the router which ports to open and close.  Since I do not trust OMMA to be a firewall (for no reason other than that they are not a firewall company) I prefer the 2nd scenario.  Besides, I know my router and how to configure it, but I know little about configuration of my OOMA device as a router.

Quick search on the web for how to setup option 2 gives: http://dailybeagle.com/2009/09/how-to-configure-the-ooma-hub-to-work-behind-a-router/  I credit this article and the posts associated with it for helping point me to the right solution – although the guidance it gave did not work for me – it did cause me to investigate the issue further.

One of the chief complaints about option 2 is that the setup.ooma.com home page is only accessible, by default, if accessed though the OOMA device’s “Home” port.  No doubt OOMA has made the device this way for security purposes.  If you could access the setup page from the OOMA device’s “Internet” port then so could anyone on the public Internet who wanted to play with your device.  Not being familiar with the OOMA device itself, but being an IT professional (this article and it’s contents are my personal opinion and not that of my employer) – I feel confident in saying that the OOMA device is designed as Firewall / NAT / QOS / Router in addition to the obvious telephony functions.  It appears to have a built in web server that serves up the setup page on it’s “Home” port address which is configurable but defaults on the Telo to 172.27.25.1.  When a PC or a router is connected to this port, the OOMA device uses a built in DHCP server to serve up an address to the PC/Router and assigns its own address 172.27.25.1 as the default gateway.  This means that the attached device will send all packets destined for remote networks to the OMAA device for routing.  The device listens on port 80, the standard http port, for traffic.  It also maintains some sort of DNS server or cache mechanism to redirect setup.ooma.com to its own home port address for those clients that forward packets to it.  I validated this by attaching a PC to my OOMA Telo’s home port and accessing both http://172.27.35.1 and http://setup.ooma.com.  Don’t get confused here – setup.ooma.com is directed to the OOMA device only when the requesting system is forwarding packets though the Home port.

Neither setup.ooma.com nor 172.27.35.1 are accessible from the Internet side of the OMAA device by default because the device is a firewall/NAT.  It is bad practice for a firewall/NAT device to expose its private network (HOME in OOMA’s case) to the other side (Internet in OOMA’s case).  However, if AND ONLY IF, you have setup your OOMA device behind another firewall, you, like me and others, may not want your OOMA device to shield you from accessing its setup page in this manner.

The dailybeagle.com article above suggests simply adding the Home port IP address to the DMZ address.  This may have worked on the OOMA Hub (I did not test) but it did not work on my OOMA Telo.  Maybe it worked on older versions of the OOMA device’s firmware.  Making this change seems logical because a DMZ is an address to which all ports are forwarded.  Forwarding all traffic coming to the OOMA device’s Modem Port to the DMZ address.  However, like many devices, the OOMA just seems to not care to forward a packet to itself.  The OMMA device has two addresses – at the MAC level:  Modem Port MAC address & Home Port MAC address.  These MAC addresses what IP addresses are resolved to in the final stage of sending traffic from device to device.  This is analogous to having both a front door and a back door on your house with two house numbers on different streets.  If you had a package in the front door to your kid and tell him to deliver the package to your own back door address – the kid is just going to stand there because the package is already there.  Firewall devices are especially sensitive to this because it would look suspicious to send traffic through the front, out the back, and then back into the back again.  Because OOMA is acting as a firewall device, I was not surprised to see this fail.  Had it succeeded I would have been deeply concerned about the overall security of the OOMA device when used in the configuration OMAA seems to prefer.

The configuration that I tried next, was the one that worked.  A port forwarding rule.  I simply setup my laptop on the home port with the default OOMA device configuration and let it grab an IP address from the OOMA’s internal DHCP server.  Then I went to http://setup.ooma.com, navigated to Settings, Advanced, scrolled down to “Add New Rule” and clicked it.  Under start port, I entered:  80.  Under TCP, I left the default TCP.  Under Forward to address, I put the Home port address used by the OOMA device, default 172.27.35.1.  I left all other fields blank and then clicked OK. Then I disconnected my laptop from the Home port and reattached it to my router.  At that point, I opened my web browser to http://192.168.1.100 (the address my router had assigned to the OOMA Modem Port’s MAC address).  I could see the setup page just fine.  Mission accomplished.  Or not.  Yes, I could access the page by IP address but not by http://setup.ooma.com.  Technically this does not seem to be a problem since the setup page seems to use relative addresses properly.  I can now just substitute http://192.168.1.100/… w whenever I need http://setup.ooma.com.  But why does this method work?  OOMA’s team has clearly decided, like many other outer teams, to allow port forwarding but not DMZ publishing of the internal address.  This port forwarding rule is like telling your kid, in the dual addressed house example, to explicitly take the package go out the back door then turn around and set it inside the door.  As the device go to forward the packets, it must send them out its network stack headed towards the remote network. It knows the forward must be to an address that is out the Home port.  However, my suspicion is that much like any other operating system network stack, at some point the stack realizes the packet is for itself and sends it back up the stack.  This is like placing a child outside the back door and having hundreds of packages are destined for you neighbors and the kid at the back door will run them to the neighbors when it gets to the back door – but if he sees and one addressed for home, he sets it back inside.  Here is a picture of the solution:

OUTDATED IMAGE REMOVED and needs to be replaced.

Now, if you really want to access this via name http://setup.ooma.com instead of whatever address your router assigned then you need to either have a router runs a DNS server, where you can add a host entry, or make a host file entry on the computer you use to manage the device.  To make a DNS entry on your router you will probably need an advanced router software like dd-wrt – and is beyond the scope of what I am willing to write.  There are other great blogs out there about dd-wrt.  Do not make the mistake of thinking you can resolve this name resolution problem by making a DHCP entry.  DHCP assigns IP addresses not DNS names (although some routers that run both may integrate the features).  Home users routers usually point at a DNS service but do not run one.

My Linksys 610N has not been updated to dd-wrt yet – and does not have a DNS server service.  To make a host file change to allow this simply open notepad.exe.  Then click file, open and enter %systemroot%\system32\drivers\etc\hosts as the file to open.

The file should look something like this:

OUTDATED IMAGE REMOVED and needs to be replaced.

After the last line enter your device’s IP address (mine was 192.168.1.100) then TAB then setup.ooma.com.  Here is my finished hosts file.

OUTDATED IMAGE REMOVED and needs to be replaced.

If you have problems saving the change, try opening notepad from the start menu, by right clicking it and choosing “Run as Administrator”.  This will likely be necessary on Windows 7 and Vista due to User Account Control.

After you either make configure your router’s DNS service or use the host method above you should be able to access http://setup.ooma.com with the option 2 configuration.  Remember to remove the forward rule if you ever revert to Option 1!

—–

Ok, so that got me access to setup.ooma.com without having to deal with the home port.  Here is the command OOMA game me to reset the handsets:

Run the following from the setup page

http://setup.ooma.com/cgi-bin/mfgdiags/frontpanel/unlock_hs.lua

After doing so, reset the phones you want to associate:

1. Go to https://my.ooma.com/account/system and retrieve your setup PIN.  You will need this in step 4 to let your TELO handset associate with your ooma device.

2. Hold down the red end-call button on the TELO handset until it shuts off.

3. Press and hold the upper right icon (radio tower) on the OOMA about 5 seconds – until it begins to flash.

4. Press the red-end call button on the TELO handset and then immediately press and hold the soft key button “-“ in the upper left hand corner while simultaneously pressing the button in the lower right corner with the circle process icon.  The handset should show “autoregistration” and then ask for a PIN if successful.  The timing is tight and if you missed the brief window for the key press – you will have to start over at step one.

I hope you find this bit of information useful.

–

David Taylor

The following two tabs change content below.

• Bio
• Latest Posts

David Taylor

Having earned more than 25 IT certifications in his career, including the well-recognized Certified Information Systems Security Professional, he has more than 25 years of technical troubleshooting experience. He is an expert with Active Directory and the underlying services that support it. In addition to leveraging his deep understanding of many Microsoft technologies, David enjoys applying systems theory to networks, applications, and other operating systems, including Linux. David has had the pleasure of providing information technology expertise to many of the Fortune 500. He has worked as a Microsoft Premier Field Engineer, as an escalation engineer for Dell, as an Active Directory Subject Matter Expert for UnitedHealth Group / Optum, and in Oracle’s Global Business Unit Cloud Services. To learn more about David's professional skill set, you can view his industry certifications and other curriculum vitae on linkedin.com. Honorably Discharged, David is a Gulf War veteran who served in the U.S. Army Reserves and the active-duty U.S. Navy. He earned the Southwest Asia Service Medal for operations in the Persian Gulf and Bahrain. He is world-traveled, well-read, articulate, and approachable. He has a unique ability to communicate to the most technical of developers, engineers, and administrators, yet equally well to the non-technical business process owners, and laymen, that rely on IT services. When not busy with work, David can be found in the company of his Sweet-Love, Alicia. Together, they enjoy playing video games, tinkering with the latest technology, or having friends over for a night of non-traditional/tabletop games. They hope to encourage people and inspire within them a passion for integrity, imagination, and technology. This blog is provided by David for you to use at your own risk and may not necessarily reflect the opinions of his employer(s).

Latest posts by David Taylor (see all)

• Personal Bill of Rights - February 2, 2020
• Vacationing with Beauty and the Beast! - September 20, 2017
• Accessing the OOMA setup page without using the Home Port - February 12, 2010
• Installing Windows 7: Unsigned DVD Driver - February 12, 2009