Got something else to discuss that is not covered by the previous forums? Post it here!
#109977 by ranger51r
Thu May 16, 2013 5:51 pm
I have had Ooma for awhile now and started to add firewall filters and security policy on my Juniper SRX210 (firewall filters are the same as an ACL). I am only doing basic lockdown right now; only permitting home addresses to access the Internet, disallowing outbound destination and inbound source RFC1918 addresses, etc. I also disallow any DNS queries to other than OpenDNS because I currently use OpenDNS (free account) to filter DNS lookups (trying to keep some of the Internet's "badness" from my young daughter). Anyway, as soon as I enable the filter Ooma appears to still work but shortly thereafter, the big blue symbol goes red. :?:

My DHCP server issued the home network address with my DNS primary and OpenDNS secondary. Thinking maybe there's an issue with the DHCP or local DNS servers, I statically set the address with only OpenDNS and the default gateway and, still, big red symbol. So it doesn't appear to be the DHCP or DNS servers.

I remove the firewall filter and restart Ooma and now the red symbol turns blue. Ok, what's going on? Connect a network tap and fire up Wireshark and the first DNS query from the Ooma device is to What? The device is statically set to use OpenDNS ( so why is it querying Since I had no idea what this was, I looked it up and this is Ooma's DNS (ns2, ns1 is .20). I also see queries to ns1 (, and a bunch to Level 3 Communications DNS ( is owned by them), NTP to Ooma's NTP servers, etc. I'm glad I captured on the "To Internet" interface because I was going to lock down NTP as well.

Why are these addresses hard-coded into this device? I can maybe see NTP and Ooma's SIP servers because that lessens what the user must configure (and mess up, which increases Ooma tech support calls) but DNS? If I can configure it why doesn't the device honor it?

Now I haven't closely looked through the packet capture so the issue may be other than DNS, meaning even if the device cannot contact all its hard-coded addresses it might still function, but the capture clearly shows the device does not honor the configured DNS servers as primary. Very frustrating. I guess my firewall filters and security policy just got more complicated and, potentially, unstable because I have no control over where Ooma decides to send traffic and if they update the device, and these addresses change, my carefully crafted filters / policy will break this box again.
#109979 by lbmofo
Thu May 16, 2013 6:13 pm
Because Ooma ran into too many issues with customers' DNS not working properly, all queries to * will go directly to Ooma's DNS servers first.
#109980 by ranger51r
Thu May 16, 2013 7:59 pm
Thank you for the information and quick reply. I did search for DNS but didn't get much; did I miss the FAQ / Tech Pub / Release Notes that discusses this behavior?

A couple observations from the capture:

The device leases an IP address but doesn't appear to use it. First event I see after device bootup is a DHCP event (discover / offer / request / ack) but first DNS query is from the statically set IP. Interesting but probably not relevant.

The connection to is TLSv1 using AES256 and SHA...very good news.

NTP requests are sent to Ooma NTP servers as well as

With this said, are there any documents that describe necessary ports / addresses / etc. for firewall configuration? Or will I need to include the addresses / protocols from the packet capture?

Again, thanks for the help. Pretty cool one can post here and get a quick, and accurate, response.
#109984 by lbmofo
Thu May 16, 2013 10:37 pm
For address info, you'd need to get info from the guys I mentioned because the dns servers you mentioned are different from what I've seen before so there maybe updated info.
#110035 by ranger51r
Sat May 18, 2013 8:14 pm
dknyinva wrote:
ranger51r wrote:..... disallowing outbound destination....
Ooma uses the following application ports for outbound data and voice traffic:

UDP 53, UDP 123, UDP 514, UDP 1194,UDP 3386, UDP 3480, UDP 10000-30000, TCP 110, TCP 53 and TCP 443. ... vice-ports

Thanks for the link. As for the quoted line, it was meant to read disallowing outbound destination of RFC1918 addresses and inbound source of RFC1918 addresses. As you undoubtedly know, although these are fully-routable address spaces, they are reserved for private use and not routed over the Internet. Hence the deny policy for traffic that cannot be anything but malicious.

Who is online

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