Continue to badger Turris / OpenWRT for enough information to do this if it can be done or a clear statement that it cannot.
Set a completely static config on the ATA i.e. don’t use DHCP on the ATA.
Move the DHCP server somewhere else. For IPv4 at least there is no real reason to have the DHCP server in the internet gateway and it can be argued that the DHCP server should not be in the internet gateway.
Increase the SIP registration period. What is it currently set to?
Set up a second “DNS server” that frontends the Pi-Hole. Everything on the network uses that new DNS server. The new DNS server has negligible logic: if source IP address is that of the ATA then relay to upstream (ISP) DNS server else relay to Pi-Hole - and handle responses coming back. (It may be that the Pi-Hole box with a second IP address could itself play this role.)
Add the needed functionality to your router. Job done. It’s open source, right?
On balance the second is probably the path of least resistance if you don’t get anywhere with Turris Support. Those last two options might require some software skills, particularly the last.
Yes, me too. Not just those conveniences but also
troubleshooting, and
it is easier to reconfigure the entire network if you have to do so, if everything is using DHCP. That is, DHCP with static mapping from MAC address to IP address is the best of both worlds - the convenience of fixed IP addresses but ease of reconfiguration (e.g. move DNS server somewhere else) if you had to.
If it is possible at all, it really won’t be that difficult.
I played at doing your 2nd one, starting at the ATA settings, changing from DHCP to Static and applying the same/current IP address… but then wasn’t quite sure how to adjust the router settings to exclude the ATA from DHCP (other than just deleting it… but that didn’t go so well. Lol. So I reverted to the way it was.
I’ve been waiting a couple of days for Turris to approve my forum account so I can get a definitive answer.
That’s complicated because routers that contain a DHCP server exhibit inconsistent behaviour regarding whether fixed mappings should be inside or outside the DHCP range etc.
(If you want me to elaborate on that point then you would have to clarify what the subset of the subnet that is being used for DHCP is and whether fixed mappings are inside or outside that range - on your particular router.)
In this case I would have just left the DHCP fixed mapping for the ATA there in the router. It is unlikely that the router will block the traffic just because it sees a device that is using an IP address that it hasn’t been validly issued (unless that functionality specifically exists in the router and you have enabled it) - and it is unlikely that a DHCP server would issue an IP address that has a fixed mapping against it to another DHCP client (hence making it highly desirable to leave the entry there, for those routers where fixed mappings are inside the DHCP range).
In other words, don’t adjust the router. Just leave it there. The DHCP server will never see a DHCP request that matches the entry by MAC address but that isn’t a problem. (On my router, I leave such an entry there because it’s a clear placeholder that the address is assigned to a device even if the device is not in fact using DHCP.)
I’ve found a way to exclude the ATA’s connections from the Pi-hole logs.
I created a new “Group” and moved the ATA into it. Then, in “Clients,” I restricted the ATA to the new group, disabling it in the “Default” group. That excluded it from filtering, but didn’t stop it from logging its numerous entries every few seconds. To exclude it from logging, the following was necessary:
In Pi-hole Settings > Web Interface/API > Exclusions, add the IP address of the ATA to the “Clients to be excluded from Top Client Lists and Query Log” box.
In the “Domains to be excluded from Top Domain Lists and Query Log,” specific domains can also be excluded, e.g. myvoipproider.com or myvoipproider.net, either as an exact match, or partial match via regex.
Then in Pi-hole’s System settings, I flushed the logs to start afresh. Now the Top Lists and Query Log display the items I actually want to see, without all the clutter from the ATA.
The total query counter still registers the “invisible” ATA queries, but at least I don’t have to wade through them.
Of course, but if SSH is turned off, it’s behind the Starlink NAT and the it doesn’t accept https log from outside the internal LAN, how vulnerable is it?
I am not intimately familiar with this exploit but I think you are missing the point.
There is a serious vulnerability in the ASUS device (some set of models).
The vulnerability is allowing the device to be taken over (arbitrary command execution).
The fact that the current way of utilising that is to enable SSH in the ASUS router is neither here nor there. A sophisticated attacker can tunnel SSH through in other ways if SSH is what they want. However you can’t even assume that SSH is all that they want.
Worst case the attacker can probably completely replace the firmware on the ASUS router and then you wouldn’t even be able to turn off SSH.
Risky but maybe. It depends on several unknowns:
Are there any paths from the internet to the ASUS router itself? (This is unknown to me but could be known to you i.e. you know your setup.)
Are there any other ways of exploiting similar vulnerabilities in the ASUS router? (This would likely be unknown to both of us but I would never underestimate the level of motivation and sophistication of an unknown attacker. I see attempted router break-ins all day every day.)
My answer would be: if your model is still supported then apply fix ASAP else pull trigger.
You haven’t clearly explained (that I could see) whether you are using double NAT and/or what the roles are of the two devices.
In any case, your starting point (hypothetically speaking) is to jump on the ASUS router and see what ports it is listening on and for those ports whether it is bound to a specific interface e.g. the LAN interface or to the ANY interface or to the WAN interface or …
In my experience with my own router the code can be very lax about this. YMMV.
As a small amount of comfort, you might run a port scanner from the internet to your outer router’s WAN IP address.
Double NAT, clean port scan and SSH confirmed off from the control panel. I admit, there was some “devil’s advocate” vibe embedded in my question and the answers were largely as expected/deserved.
I’m gonna buy the Omnia. Once it is configured and in service I’ll try to salvage the ASUS with OpenWRT. Never flashed a home router before, so it should be fun. If all goes well, I put the winner in service and still have a great spare.
Looking at price, VAT, and international shipping to USA, I decided to keep the expenditure to about the same as I spent on the ASUS about 10 years ago… I went with the Flint 2. I’ll try to set it up this weekend.
It’s open source, right?