Need extra help installing your Ooma Hub or Telo system? Let us know.
#41476 by indie_dev
Tue Jan 12, 2010 11:45 am
I have an Ooma Telo and after testing it through both 2A and 2B configuration options (both of which work fine), I wanted to share my findings with those who find this sort of information useful.

I will not disclose my advanced testing methods because I don't particularly want some miscreant harvesting the information and using it for nefarious purposes.

First of the bat, absolutely - positively - DO NOT - use Ooma's Option 2A configuration if you value the security of your network, let alone your privacy. Especially if you are running in internal LAN that hosts sensitive material.

Option 2A allows you to plug the Ooma device BETWEEN your modem or router. DO NOT DO IT!!. Let me explain why.

Rather than go into any technical details which will just serve to confuse the issue, let me explain in layman terms what is going on starting from the beginning.

My Configuration:

LAN: six machines (five desktops + 1 laptop)
D-Link DIR-655 [wireless] router
D-Link DGS-2208 Gigabit Switch
Motorolla SB6120 Modem (cable modem)

Test with Option 2B (Ooma device BEHIND the modem & router)

Since the router has all the security protocols, it handles things like firewall, port forwarding, virtual servers etc. It also has built-in QOS rules (more on this later). These rules are essential for accessing LAN side configurations such as VPN, php server, web server, SVN server etc etc. All of these are accessed using a combination of port forwarding and virtual servers on the router.

The router is set to obtain an IP address via DHCP from the cable modem.

The router is set to provide addresses to the LAN side via DHCP. It also has some rules for static IP allocation to machines that require it. In those cases, the IP is reserved in the router's DHCP table so that it never expires nor can it be revoked without manual intervention.

After I installed the Telo using Option 2B (Telo INTERNET port connected into spare router port) and it downloaded the update (less than 2 mins) and such, everything worked just fine.

But since the Ooma was assigned an IP address by the router and in a range that is totally different from the Ooma's own internal range, I could not access http://setup.ooma.com to see what settings were on the device.

So since my primary desktop has two network interfaces, I simply connected a spare RG45 cable into that second LAN port and into the Telo's HOME port and was able to access it.

NOTE: that all the machines (as well as a pair of NAS devices) are connected to the switch (connected to the router). A PowerLine AV (a HomePlug device) bridge as well as a network printer are plugged directly into the spare (one of which the Telo is connected to) ports (it has four) in the router. The laptop (and other devices, e.g. smartphone, PSP etc) access the internet via wireless through the router.

As soon as I was able to access the Ooma config, it hit me. There is NO password on that Telo interface. And THAT is what sparked my research into what I consider to be a major privacy/security breach.

To test my theory, I ran a test using the second (and Ooma RECOMMENDED configuration)

Test with Option 2A (Ooma device BETWEEN the modem & router)

- turned OFF the Telo, modem, router

- connected the Ooma device as per Option 2A (HOME connects it to the router and INTERNET connects it to the modem)

- turned on the modem and waited for it to fully initialize (all relevant lights on etc)

- turned on the Ooma device

In the Ooma device config, I set it to DHCP (instead of automatic) and for it to use the internal MAC address. Saved everything.

Everything connected just fine. Made a phone call. Called myself from a cell phone. All OK.

I go to the Telo config page (172.27.35.1) - which I can now access just fine due to the new connection config and checked the status. All OK.

I could NOT access any services (e.g. web server, SVN etc) on machines located my LAN side machines from outside the Internet (using my smartphone via the cellular network). Why? Because their ports are forwarded by the router - which is now assigned a DHCP by the Telo and thus knows nothing about the inbound traffic from the Internet via the Telo.

I go to the Telo config page and set the DMZ to be the IP (172.27.35.105) address it had assigned to the router.

Still could not access any LAN services from the Internet. Conclusion: The Ooma device DMZ does NOT work correctly. Great.

So I decided to try one test at a time. I started with my Subversion (SVN) port by adding it to the Telo's port forward page so that the port was forwarded to the 172.27.35.105 IP of the router. Then I tried it again from my smartphone. It worked.

I then added and tried my VPN, FTP, NAS etc ports. All worked when accessed from the internet as long as the ports were forwarded in the Telo to the router's IP address.

This is the part where I totally freaked out.

From the browser (Opera) on my smartphone, I input the router's 172.27.35.105 IP and was HORRIFIED when - from across the Internet - I was staring at the Telo config page - which was supposed to be sitting at 172.27.35.1 and not accessible outside the LAN.

To make sure I wasn't losing my mind, I called my wife at work and asked her to do the same thing. She too was able to access the Telo's config page and was able to not only see ALL the config pages, including the previously configured ports that were forwarded, but also the landline phone number (I opted to keep my own landline) etc.

Went back to the Ooma device and deduced that since the router's IP was now in the DMZ, the Ooma config page is now accessible from the open web!! EDIT: Someone also posted about this here.

Now the whole wide world has access to your Ooma device. And since your router's IP is in the DMZ, they have access to your LAN ports as well since they can control the Ooma.

Imagine what would happen if some nefarious person who somehow obtained your IP address (there are MANY ways to do this) were to access your Telo/Hub device. Then use the Ooma port forwarding and DHCP interfaces to wreak all sorts of havoc. As I type this, I can think of no less than a dozen things that anyone who has any knowledge of this sort of thing can do - and with ease.

Apart from the security/privacy breach implications, sticking your Telo or Hub device behind your modem/router, pretty much means that everything you previously configured in your router, goes bye-bye and would have to be handled by the Telo. EVERYTHING.

Of course when you factor in that the Telo DMZ just does NOT work [to forward all ports to your router and thus your LAN], you can see where this is going if you have a pretty advanced setup e.g. you work from home, need to access your LAN from work/home etc.

Apart from the DMZ not working, a bunch of ports on the Telo don't seem to work either. e.g. try forwarding TCP or UDP 8888 and it won't work. It appears as if the Telo device either hijacks or reserves various web ports (e.g. 80, 88, 8888 etc) for itself. So if you use those ports on any device on your LAN, forwarding them from the Telo to your router will not work at all.

So here I am wondering why on Earth these Ooma folks decided to have an interface that has ZERO security options.

Heck, even modems, routers etc come with bare minimum security interfaces with default values which can be changed at any time.

And without ANY sort of security, they're advising people to stick their Telo/Hub device BETWEEN the modem/router and thus completely bypassing whatever security features either of those two devices can provide. For the most part, cable modems are "pass through" devices, which unlike DSL modems and routers, have NO configuration interfaces whatsoever.

As to the QOS issue, any decent router these days has built-in rules. You can then use the IP address of the Telo in those QOS rules and achieve pretty much the same thing without exposing your Telo/Hub device to the world at large. For any decent VOIP performance, you don't need to reserve anything more than 128Kbps. And if your router has built-in QOS rules, all you need to do is to set the traffic from the IP address of the VOIP device to have high priority.

Now ask yourself this. Do you think the Ooma engineers have more experience and knowledge in QOS bandwidth shaping than the modem/router engineers who have been doing it for decades? So why would you compromise your security/privacy just to eek out a little bit of bandwidth just because Ooma tells you that by sticking your UNPROTECTED Ooma device behind your modem/router, your calls will be that much better?

Just don't do it. Stick with config Option 2B.

There are NO warnings on the Ooma docs, support pages, FAQ or anywhere warning about the dangers of using Option 2B as well as the DMZ. Then again, the Ooma config page has no protection whatsoever.
Last edited by indie_dev on Tue Jan 12, 2010 4:13 pm, edited 2 times in total.
#41478 by bw1
Tue Jan 12, 2010 12:07 pm
I guess I'm confused.
This is what the Telo Quick Start Guide says:
Option 2A: Connect between your modem and router (recommended)

Option 2B: Connect behind your integrated modem/router

So Option 2A would have this setup:

modem - Telo - router - 1 or more computers

This is referred to as Ooma in front of router.

Option 2B would have this setup:

modem - router - 1 or more computers plus Telo connected to separate ports on the router

This is referred to as Ooma behind router.
#41479 by Aveamantium
Tue Jan 12, 2010 12:15 pm
bw1 wrote:I guess I'm confused.
This is what the Telo Quick Start Guide says:
Option 2A: Connect between your modem and router (recommended)

Option 2B: Connect behind your integrated modem/router

So Option 2A would have this setup:

modem - Telo - router - 1 or more computers

This is referred to as Ooma in front of router.

Option 2B would have this setup:

modem - router - 1 or more computers plus Telo connected to separate ports on the router

This is referred to as Ooma behind router.

Thanks BW1, I was just going to post this same thing... :?
#41480 by tjkirk
Tue Jan 12, 2010 12:17 pm
Yes, I am confused too. Interesting research, but I think your recommendation is to put the Telo behind the router, correct? Not Option 2A, which is in front of the router and thus causes the security vulnerability.
#41481 by Aveamantium
Tue Jan 12, 2010 12:21 pm
tjkirk wrote:Yes, I am confused too. Interesting research, but I think your recommendation is to put the Telo behind the router, correct? Not Option 2A, which is in front of the router and thus causes the security vulnerability.

I'd agree! When I started to read this I thought he was going to say that option 2B opens up a "back door" to the NAT on a router!? Now that would be a scary thought! :o
#41483 by murphy
Tue Jan 12, 2010 12:29 pm
Please read this post.

viewtopic.php?f=8&t=5774

As long as you don't implement either of the tricks for accessing the config via the ooma WAN port or loop the Home port back to the router there is no access path.
#41484 by Groundhound
Tue Jan 12, 2010 12:31 pm
indie_dev wrote:From the browser (Opera) on my smartphone, I input the IP address assigned to the router by the Telo and was HORRIFIED when - from across the Internet - I was staring at the Telo config page!!

Confused me too. If your Telo is behind your router as described in 2B, why would your Telo be assigning an IP to the router?
#41488 by caseybea
Tue Jan 12, 2010 12:47 pm
It's so cool when people set up up networking improperly, and then get all freaked out when they've accidentally exposed something. While you probably have a fair understanding of your home network's setup, you're missing understanding the setup of the ooma device vs the LAN port vs the DMZ and what is, or is not, exposed.

Phrased more simply, I'm sorry to say that you messed up. If set up properly, the web interface for the ooma device is NOT accessible outside of your home network. This is regardless of whether or not the ooma is in front of or behind the router.

There are several posts in this forum that describe how to set up the web interface and yet not expose it to the outside.
#41508 by indie_dev
Tue Jan 12, 2010 2:30 pm
Sorry for the confusion everyone. It is a long post and I got the config naming convention incorrect. But thats the extent of it.

The sheet I got with the Telo indicated that 2B was the best option for QOS of the telephone traffic. That is the option that (a) poses a risk as described (b) will completely kill any advanced config that you have going on in your modem/router and thus you delegate all those tasks from your more capable modem/router to the vastly incapable Ooma device.

caseybea wrote:It's so cool when people set up up networking improperly, and then get all freaked out when they've accidentally exposed something. While you probably have a fair understanding of your home network's setup, you're missing understanding the setup of the ooma device vs the LAN port vs the DMZ and what is, or is not, exposed.

Phrased more simply, I'm sorry to say that you messed up. If set up properly, the web interface for the ooma device is NOT accessible outside of your home network. This is regardless of whether or not the ooma is in front of or behind the router.

There are several posts in this forum that describe how to set up the web interface and yet not expose it to the outside.


Wait. Is this the part where the local denizens try to attack the new guy? If that is the case, let me share some facts with you.

1. I'm not a n00b. So yes, I do this stuff for a living - and for much longer than most have had hot dinners.

2. My test experience is EXACTLY as I indicated or I wouldn't have posted about it. I ran the test several times.

3. If I wanted to make waves, I'd have created a post about it on my dev blog (which gets more traffic than this forum at any moment in time). But no, I simply wanted to make those smart enough to take their security/privacy seriously, be aware of the security risk. YMMV.

So please, refrain from making unqualified statements and go run the test yourself. You do NOT need a complex setup as mine. In fact, I sent this post to a friend of mine at Secunia and his first comment was that the fact that the OoMa interface had no password is the first sign of a security breach.

I don't care really, so go ahead and do what you want.
Last edited by indie_dev on Tue Jan 12, 2010 2:36 pm, edited 1 time in total.

Who is online

Users browsing this forum: Google [Bot] and 4 guests