How to redirect hard coded IOT device DNS/NTP query to working external DNS name or IP?

FerrariGuy · December 23, 2021, 7:00am

I've gone a bit crosseyed trying to find and understand the ways program the OpenWRT firmware to take a DNS/NTP query going to an external IP hardcoded into an old IOT device (Ooma Hub VOIP device) to a working DNS name or IP. I'm just not experienced enough to translate what others have done for similar issues into what to do in my firmware to make this work.

What's happening:

I have an old Ooma hub wich reaches out to 208.83.244.20 and .244.21 on ports 53 and 123 in order to begin connecting to the Ooma VOIP network. The reverse DNS on .244.21 is ns2.ooma.com, but an NSLookup to ns2.ooma.com to just about any DNS server says its .246.21, not .244.21. Ooma Tier 3 service people imply that .244.20 and .21 are still up and working, but tracert to those IPs (from some locations apprently) says there's a backbone problem where communication dead ends out at us.zip.zayo.com (confirmed by a lot of owners of this device - see the Reddit Ooma section). There's no telling if Ooma's engineers (who have been alerted to the problem) will take the time to work with the tech support in that part of the backbone to resolve an issue for old out of warrenty unsupported devices either. That means a factory reset of the device doesn't work for some of us.

There are a number of savvy users who've redirected the .244.21 (or 20) queries to either Google's 8.8.8.8 or an actual reachable Ooma DNS (208.83.246.21), and their device begin working fine again.

I've tried using SSH Putty to send this command:

iptables -t nat -I PREROUTING -d 208.83.244.20 -j DNAT --to-destination 8.8.8.8

But I later read read why this command wasn't working (because OpenWRT depreciates iptables to be managed with FW3 apparently which.. I'm just not familiar with any more so than I fully understand iptables.) (per tab and per-field instructions would be great if I could ask for that...)

Do I need a plugin to make this happen? Will I have to manually write this into one of the files on the device?

Is it easier to do this substituting one IP for another instead of an IP --> DNS name (like a reverse host file entry). I think I'd prefer a reverse host entry so that ns2.ooma.com is always whatever is reachable, but if that's more complex than direct IP substitution I might reconsider.

Sorry for being too much of a newb to really ask the questions well, or understand the various solutions worked out by others for similar problems.

~FerrariGuy

OpenWrt 21.02.1 r16325-88151b8303 btw. WND3700 Netgear V1 (low memory) if it matters.

frollic · December 23, 2021, 7:35am

Redirect all calls from the devices' IP/MAC on port 53 (and 123?), to 8.8.8.8 ?

FerrariGuy · December 23, 2021, 7:46am

That might work, but I'm not 100% sure how to do that. AFAIK Tell, although I know it's trying to get to destination ports 53 and 123, I dont' have packet captureing setup so IDK what high ports it might be coming from. If it's just 53 to 53 and 123 to 123 fine. But I can't set up a rule that says ANY TCP traffic from that device goes to x external DNS erver on port 53, because that ignores the need to do the same for 123, and also subsequent communcations from the device elsewhere later in its operations.

EG for DNS: (1.8 being a dhcp assigned address for the Ooma IOT device).

What happens if the DNS query source port could be anything? Same for query for NTP?

Maybe I misnunderstand, but would that set up a collision of rules?

frollic · December 23, 2021, 7:47am

source port should be any, add UDP to protocols.

same for NTP, yes.

but does 8.8.8.8 provide a NTP service ?

FerrariGuy · December 23, 2021, 7:51am

Ok.. I think I understand now.

Source can be ANY, the filter will say IF to .244.21 and port 53, substiute .246.21 to 53

and write a similar rule for port 123.

I'll try this. IDK why this wasn't more obvious to me. Thanks!

IDK if 8.8.8.8 provides an NTP service, but I can certainly find an Ooma NTP server for that rule.

FerrariGuy · December 23, 2021, 8:05am

Untried as of yet, but these are the 4 rules for the two broke IPs I've setup. We'll see how this works out:

192.168.1.8 being the DHCP LAN Ip assigned to the Ooma IOT MAC)

~FerrariGuy

frollic · December 23, 2021, 8:07am

you can merge the TCP and UDP rules into one, the protocol entry is changeable.
any zone should probably be LAN, unless you have some kind of IoT network set up.

FerrariGuy · December 23, 2021, 8:26am

So far, not working.. I'll let it sit for a a while. (At least two other people have made this work so....)

I agree any zone should be LAN, unless I Put the thing on an IOT zone.

This is what I see in the log. Not sure if there's a way to see if the NAT to the other IPs are working. It's all UDP accordign to the streaming connections.

No luck yet. so either this will take some time, I'm doign something wrong, or there is some bigger problem.

frollic · December 23, 2021, 8:41am

depending on where/how you look, the traffic you see is before it hits the firewall rule.

you might want to try tcpdump on WAN.

FerrariGuy · December 23, 2021, 9:10am

Looks like this may be a longish term problem. I'll need another device to either man-in-the-middle observe traffic, or a router with more memory so I can install more packages like tcdump on the router. I put ZeroTier on it so I could SSH into the lan side, and that pretty much wiped out the spare memory.

Setup for the Ooma is IOT Ooma --> OpnWRT Netgear --> XFinity Gateway/Router.

So the OpenWRT box is on my lan, and the Ooma is on the LAN behind that. The idea of using the OpenWRT box was to do what the Xfinity box coudln't (and observe trafic).

So far there's no indication that the rules are doing what has allowed others go get their boxes back up and running. I"ve even tried shifting the DNS rewrite address to google's 8.8.8.8 and the time server to Ooma's time.ooma.com IP.

I can see when my router's external IP hit's xfinity up for a DNS query OR NTP query on port 53/123 it does so with 2 packets, while the Ooma DNS query's to either only show 1 packet. Not sure if that's important or not. Same for the OpenWRT's time querys to comcast. Although, weirdly, the Ooma IOT sometimes hits up the OpenWRT's gateway address (192.168.1.1) for a port 53 query with 2 packets (rarely).

(Box assgined to 10.0.0.80 on the lan for it's WAN IP)

frollic · December 23, 2021, 9:19am

so the screen shot is from the xfinity, or .... ?

FerrariGuy · December 23, 2021, 9:30am

These are screenshots fromt the LuCI OpenWRT interface - XFinity happens to be the ISP (apparently the router directs some queries to comcast servers).

Also, the rules setup are SNAT? Yes?

But at least for some other systems DNAT is /can be used to achive the rerouting I want?

I ask because in 2 other systems the instructiosn for setting them up vary a bit.

E.g.

These are the instructions that worked on an Asus router:

Quote:

ISP: Xfinity

Network configuration: internet < modem < home router < LAN clients + Ooma Hub

Router: Asus RT-AC68U with Asuswrt Merlin firmware

I had the stock firmware in my router, and in order to do a static NAT route as indicated by @fltcpt, that wasn't possible. After a bit of research, the Asuswrt Merlin firmware supports iptables commands, so that was the ticket. Updated my stock firmware to Asuswrt Merlin latest stable release (https://github.com/RMerl/asuswrt-merlin.ng/wiki).

The basic steps after installing Merlin are:

In router gui, enable JFFS partition scripts (Administration/System/Enable JFFS custom scripts and config)
In Windows shell, launch SSH to the router. You'll want to use the -l command line switch to specify the user name.

2b) Create a file named /jffs/scripts/nat-start with the following 2 lines:

#!/bin/sh

iptables -t nat -I PREROUTING -d 208.83.244.20 -j DNAT --to-destination 8.8.8.8

I used vi as an editor to create this file. If you create a file in Windows, use Notepad++ or some other text editor where you can save the text file with Unix-style line endings. Using Windows Notepad will not work.

2c) chmod a+rx /jffs/scripts/*

2d) exit

End Quote

And for a Ubiquity router:

Quote:
For those with a Ubiquiti Edge router, you do the following:

go to the Firewall/NAT tab
click on NAT
Add a 'destination NAT rule'
Inbound interface switch0
translations 208.83.246.20
all protocols
Dest address 208.83.244.20

End Quote

(From thread: https://forums.ooma.com/viewtopic.php?f=9&t=24321&sid=df01b4080e38cd74d1c02bbb505f3c30&start=10)Preformatted text

frollic · December 23, 2021, 10:42am

US ISPs are allowed/known to hijack your DNS calls, if that's what happens here, your redirects won't work, but if that's the case, they would never reach the ooma.com DNSes in the 1st place.

if you opted out, try opting in, if doable.

FerrariGuy · December 23, 2021, 6:47pm

That's probably true, but even though I don't think that's going on here, it shouldnt' matter. I think the Ooma box only needs to actually make contact with working DNS and NTP servers from any source - they don't have to be Ooma's. At least that's the experience of others who've made this work.

Given mine is searching for the same type of communcation (that's provably unreachable) one would surmise I have the same problem, fixable with a working redirect ---- which isn't currently working for some reason. And I'm not sure at the moment if it's the wrong use of rules in OpenWRT, not enough rules in OpenWRT, a problem with the firmware actually following rules (at least NAT rules are working to let me remote manage the Ooma box through port forwarding port 80), or if there is some further HW issue with the box (seems unlikely).

I might just pick up one of those Ubiquiti routers since instructions for those are clear, and they're pretty cheap... VS trying to dive futher into adding more equipment to observe what traffic is and isn't going on.

FerrariGuy · December 24, 2021, 12:55am

I've solved this myself. The SNAT rules above did nothing. What was required was two lines added to the custom rules in the firwall tab:

I saw a post that had lines using the iptables command added to the custom rule section, and figured that might be THE way to get FW3 to use a known iptables command and it worked.

iptables -t nat -I PREROUTING -d 208.83.244.20 -j DNAT --to-destination 8.8.8.8
iptables -t nat -I PREROUTING -d 208.83.244.21 -j DNAT --to-destination 8.8.8.8

8.8.8.8 probalby isnt' the only IP to redirect to would work. Surely 208.83.245.20/21 would also work (along with others) but I'm leaving it alone now since my Ooma Hub IOT VOIP device is now working again, and proves there was nothing wrong with the box/hardware.

~FerrariGuy

FerrariGuy · December 24, 2021, 3:53pm

For anyone who might be following up in the future with an Ooma Hub Device, another discovery has occured.

After the firewall rules above were applied, traffic was redirected, and the system automaticallly went blue, I noticed a bit later that it was suddenly communicating to port 123 and 53 to new different DNS's including .246.21 that it's not being redirected to do.

When this started the device showed (Device Status - Rev: 63962.63962) which is a firwmare from 2012 according to the Ooma forums. The device now shows Device Status - Rev: 105153.105153.

Apparently getting the unit up and running bootstrapped it so that it could update to a new firmware (probably very recently issued - I assume to deal with network changes that Ooma doesn't want do discuss). This may be why some people have success simply by rebooting their unit. Perhaps there's an in-between firmware that allowed them to recive an update after factory reset, whereas some folks, including me were stuck with a firmware that rememberd to contact IPs that were no longer reachable. Given these units are rarely shut off, it makes sense thatthe firmware update might be part of a boot-up / first communication routine rather than some sort of regular chron job.

system · January 3, 2022, 3:54pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.