So far, I’m impressed by the Turris Omnia. The setup defaults in the simpler of the two interface versions (“reForis” vs. “LuCI”) helped.
It took some research to find out how to add the RaspberryPi/Pi-hole into the mix, but I got that set up, as well, in LuCI.
The only thing I haven’t figured out yet is how to force one device, the ATA for my VOIP line, to not route through Pi-hole. I don’t need to filter that one… and it generates lots of log entries in Pi-hole. So, I would prefer that the ATA use the router’s upstream DNS instead. Still trawling through Turris and openWRT forums looking for the answer.
That would depend on how the ATA gets its network parameters. Does the ATA use DHCP or is it statically configured?
If it is statically configured then it should be easy enough to specify the DNS server IP address that you want to use. So I assume DHCP.
If it uses DHCP then the next question would be … where is the DHCP server? In the Turris? Somewhere else? If it’s in the Turris then you would be looking for more advanced DHCP server functionality whereby there is a default set of network parameters that is handed out to every DHCP client but that can be overridden, in whole or in part, for specific DHCP clients?
If you can find a text file that is used to configure the DHCP server, maybe private message me with a representative sample. Or is the DHCP server only configured through a GUI?
To be honest, in my environment, the DHCP server can’t do different configs for different clients, and every DHCP client uses the same DNS server, and hence the ATA just goes through the local DNS server like everything else. With the understanding that everything about my environment is different from yours, this doesn’t seem to cause a problem. Yes, I can see a lookup for sip.<censored>.net.au from the ATA about once every half hour (probably actually the SIP registration period, which you may be able to lengthen if it is bugging you).
Yes, it could. I would have to be able to distinguish between legitimate remote access/management requests and requests to the minipot - and, not owning a Turris device, I don’t have enough information to do that.
In AsusWRT-Merlin, my router provided DHCP. I gave every device, including the ATA, a static IP (for ssh/sftp/bookmarking convenience), and made the router broadcast the Rpi/Pi-hole’s IP address for DNS. It was easy to exclude the ATA and tell it to instead use the router’s IP for upstream DNS (Quad9).
In the Turris, too, the router provides DHCP. I’ve assigned a static IP to every device using the reForis (simpler) interface, and made the router broadcast the Rpi/Pi-hole’s IP address for DNS, as per comment #1here, in the “DHCP and DNS” section of the LuCI interface. (You can use either interface after logging into the router.)
In the Turris, I haven’t yet found a setting for assigning an alternate DNS server per device. Maybe it’s not possible, which is not necessarily a big deal for me, but it would be nice to exclude the ATA and its 10,000+ daily “hellos” to my VOIP provider from Pi-hole. (And there’s nothing to block there, anyway.)
With OpenWRT, I think it’s possible to do a lot of configuration via ssh, but I’m not sure I want to go there.
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.)
It’s open source, right?