What's new

AdGuardHome Asuswrt-Merlin-AdGuardHome-Installer (AMAGHI) cont.

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Thanks for the info. I put AdGuard on hold for a bit as I am trying to work out some IPv6 issues in order to get the name resolution I desire. I've seen something in the issue tracker about privacy concerns, but I'm not entirely sure they are warranted. If you are using GUAs in your environment, the idea is they are publicly routable anyway - so there should not be a concern if those are made visible to the outside.
It seems the concern should only be with stateless/SLAAC addressing when privacy extensions are not enabled. In which case a device's MAC might get leaked. Or perhaps the concern is simply tracking based on IP - whereas with IPv4 and NAT you simply know that the device is originating from the single public IP, here you know the specific GUA accessing. I wrote my observations up here:

I'm interested in specifically how you judge this as a privacy concern? Of course I agree that the WHOIS approach should be able to be disabled if you choose not to use it. I could not find anything about doing this, but I assume (since you reference the YAML) that the appropriate section is:

Code:
clients:
  runtime_sources:
    whois: true
    arp: true
    rdns: true
    dhcp: true
    hosts: true

Because I could not find anything about it, I don't know what the danger is of disabling WHOIS. I think the only time having WHOIS might be useful is if you are running a publicly accessible AdGuard server and accessing it from outside your network where an incoming client might not be registered. However since it is unlikely that another external client has a PTR record, it seems the best you are going to get with WHOIS is an OrgName. I suppose that's better than nothing, but it's not much :)



Good to know. I have some concerns about the additional packages mostly because I have some other outside constraints (which I won't detail here) about the Entware install getting too large, but I don't actually know if this will be a problem or not for me.
I wasn't personally worried about Apache - because I'm not using it - I was just concerned on my first quick glance through of the code base that I saw it was getting removed.

What mechanism do/can you use to ensure that Apache only gets removed if it was installed by the installer itself?
Well first of all, WHOIS is mainly used in adguardhome for identifying devices with remote addresses. (e.g. you set adguardhome up to act as a remote DoH server, you connect with your cellphone via a DoH application while away from home. Adguardhome identifies your cellphone based on its public ip address, and you know through the logs that it was your cellphone connecting.) However, if you are connecting over wifi via your cellphone, adguardhome should not be attempting to query your ISP (entries in /etc/resolv.conf) to identify the hostnames of your local devices on your private network, it doesn't with distinguishable non-public routable addresses like 192.168.1.3; however, if I make stateful ipv6 address assignments without defining a upstream for the ipv6 stateful arpa, then adguardhome uses whois to request for the hostname similar to how it does with stateless addressing of the same prefix. In general, whois should not be used to identify clients within one hop of the adguardhome server. In this instance, hostname lookups should be handled by local means(e.g. arp cache, or local reverse lookup). The problem with relying on the upstream to return a hostname for a local client is that it can return anything that is inside the upstreams cache. For some people, this might seem okay, but for others who rely on local name resolution to be reliable, this could pose a problem. The ramifications could range from something minor, to something major. However the case may be, I would rather it return nothing (or what I have defined in /etc/hosts.), than to return what goggles, cloudflair, squad9, or my isp thinks it should be.
 
Last edited:
Well first of all, WHOIS is mainly used in adguardhome for identifying devices with remote addresses. (e.g. you set adguardhome up to act as a remote DoH server, you connect with your cellphone via a DoH application while away from home. Adguardhome identifies your cellphone based on its public ip address, and you know through the logs that it was your cellphone connecting.) However, if you are connecting over wifi via your cellphone, adguardhome should not be attempting to query your ISP (entries in /etc/resolv.conf) to identify the hostnames of your local devices on your private network, it doesn't with distinguishable non-public routable addresses like 192.168.1.3; however, if I make stateful ipv6 address assignments without defining a upstream for the ipv6 stateful arpa, then adguardhome uses whois to request for the hostname similar to how it does with stateless addressing of the same prefix. In general, whois should not be used to identify clients within one hop of the adguardhome server. In this instance, hostname lookups should be handled by local means(e.g. arp cache, or local reverse lookup). The problem with relying on the upstream to return a hostname for a local client is that it can return anything that is inside the upstreams cache. For some people, this might seem okay, but for others who rely on local name resolution to be reliable, this could pose a problem. The ramifications could range from something minor, to something major. However the case may be, I would rather it return nothing (or what I have defined in /etc/hosts.), than to return what goggles, cloudflair, squad9, or my isp thinks it should be.
Yeah, I mostly agree. I even think that the Whois data for external clients is mostly meaningless. So you know you had a connection from someone on the T-Mobile network - so what? You have no idea if it was you, or your brother, or someone who happened to get a hold of your address - its almost meaningless. My whois on my IPv6 over mobile right now doesn't even show my right state!

That being said I'm all for providing flexibility. And while I also agree that you probably never want/need to go outside your own network for name resolution (whether public or private), some people might have the need.
As it stands, the solution is to simply to make sure that you have all your in-addr.arpa zones setup and populated correctly (again, not always an easy task as per my notes in the GH comments).

I can't really think of a "major ramification" of getting a WHOIS lookup for a public IP that doesn't resolve locally. Sure you preference might be for it to be empty rather than a meaning less ATT record, but I struggle to see anything other than an aesthetic issue.
They could probably do with enhancing their syntax for defining upstream servers in the DNS settings page. Some qualifiers after you define a zone for the order you wish to perform resolution in per zone may be the best option.

I'm still trying to figure out the best way to handle my addressing as I am not yet reliably getting IPv6 PTR RR for even my windows clients. I have the Asus handling IPv6 addressing but an AD server handling DNS and DHCPv4. I think I need to either move to entirely stateful and either move it over to my Windows DHCP, or else use static reservations and manually add the PTR. This however will screw with Android clients, so I need to do more testing in a stateful + SLAAC implementation as I was seeing some mixed results with the clients registering all of their addresses as well.
 
AGH is installed on my RT-AX86U through the AMTM menu. I found an extraneous IP address in the AGH query log. Where could he come from?
 

Attachments

  • 1.jpg
    1.jpg
    29.7 KB · Views: 89
AGH is installed on my RT-AX86U through the AMTM menu. I found an extraneous IP address in the AGH query log. Where could he come from?
Looks like one of the devices on your network, perhaps a cellular device is connecting and checking the connection before making full connection over your network wifi. This means the device hasn't yet got its internal network ip from the dhcp (dnsmasq) so all you see is its public address at first. Once it determines it can connect, it will recieve an address from dhcp and you won't see the public address any more.
 
AGH is installed on my RT-AX86U through the AMTM menu. I found an extraneous IP address in the AGH query log. Where could he come from?
Either that, or you are connecting over a VPN on a cellular device, instead of seeing the an ip in the subnet of the VPN, you are see the public IP address of the device which is accessing the dns server via a vpn site tunnel. The first suggestion is most likely the culprit as I do not think a vpn site tunnel would produce such results by the default merlin setup.

To be honest, I am just as skeptical as you are about it. Did you open your port 53 up on the firewall? Or setup adguardhome as a remotely accessible encrypted dns server?
 
Last edited:
Looks like one of the devices on your network, perhaps a cellular device is connecting and checking the connection before making full connection over your network wifi. This means the device hasn't yet got its internal network ip from the dhcp (dnsmasq) so all you see is its public address at first. Once it determines it can connect, it will recieve an address from dhcp and you won't see the public address any more.
Either that, or you are connecting over a VPN on a cellular device, instead of seeing the an ip in the subnet of the VPN, you are see the public IP address of the device which is accessing the dns server via a vpn site tunnel. The first suggestion is most likely the culprit as I do not think a vpn site tunnel would produce such results by the default merlin setup.

To be honest, I am just as skeptical as you are about it. Did you open your port 53 up on the firewall? Or setup adguardhome as a remotely accessible encrypted dns server?
There is only one port open in my firewall - one port forwarded to port 9 to wake on WAN my NAS. I have one VPN server and two VPN clients on my router, but their private ip adresses start at 10. Queris come from the ip 11.41.108.58, which is external. I did not connect to my home network through the VPN site, and this is not possible on my configuration. I also think it has to do with the wifi connection of my samsung phone. But the IP address is strange. This IP cannot be the external IP of my phone, because it is not in the range of the IP of my mobile operator. The external ip address of my vpn site is completely different. Previously, I also had requests from extraneous IPs, but they started from 10, although they also had nothing to do with the IPs of my vpn clients and vpn servers. After their appearance, just in case, I changed the administrator password of the router, and all precautions were taken to prevent access to my router from the Internet, I never even opened port 53. I have noticed that such queris often appear when I leave the house and the phone loses home Wi-Fi, but they also appear when I am at home and my phone is connected to Wi-Fi. During this night, the number of requests from IP 11.41.108.58 has already become 28. Maybe this is also due to the instability of Wi-Fi. On my RT-AX86U firmware Merlin 388.2_2.
 

Attachments

  • 2.jpg
    2.jpg
    63.8 KB · Views: 81
Last edited:
There is only one port open in my firewall - one port forwarded to port 9 to wake on WAN my NAS. I have one VPN server and two VPN clients on my router, but their private ip adresses start at 10. Queris come from the ip 11.41.108.58, which is external. I did not connect to my home network through the VPN site, and this is not possible on my configuration. I also think it has to do with the wifi connection of my samsung phone. But the IP address is strange. This IP cannot be the external IP of my phone, because it is not in the range of the IP of my mobile operator. The external ip address of my vpn site is completely different. Previously, I also had requests from extraneous IPs, but they started from 10, although they also had nothing to do with the IPs of my vpn clients and vpn servers. After their appearance, just in case, I changed the administrator password of the router, and all precautions were taken to prevent access to my router from the Internet, I never even opened port 53. I have noticed that such queris often appear when I leave the house and the phone loses home Wi-Fi, but they also appear when I am at home and my phone is connected to Wi-Fi. During this night, the number of requests from IP 11.41.108.58 has already become 28. Maybe this is also due to the instability of Wi-Fi. On my RT-AX86U firmware Merlin 388.2_2.
Or it could be an issue with adguardhomes ability to properly identify clients. You may want to consider cruising on over to adguardhomes main github and open an issue.

From what I could tell, this could easily be a device on your network such as a cellular device, that is having a hard time remaining connect (or receiving) an ip address from your dhcp server.

Another possibility I haven't quite thought of is that could be the ip address of your router itself making queries. It would be weird if that were the case. Or a device that is connected over to a vpn client who still queries back to the main router DNS service for these types of requests. (For example, I have friend who has a government job that requires use of a private vpn to access government assets. The laptop when connected to the vpn network still queries the routers dns server from time to time for innocent queries such as these ntp server queries.)

One way to quickly find out who's device it could be is to use skynet to manually ban that IP address from your network. (It should be noted that doing such is a bit on the extreme side for what appears to be innocent client queries).
 
Last edited:
Or it could be an issue with adguardhomes ability to properly identify clients. You may want to consider cruising on over to adguardhomes main github and open an issue.

From what I could tell, this could easily be a device on your network such as a cellular device, that is having a hard time remaining connect (or receiving) an ip address from your dhcp server.

Another possibility I haven't quite thought of is that could be the ip address of your router itself making queries. It would be weird if that were the case. Or a device that is connected over to a vpn client who still queries back to the main router DNS service for these types of requests. (For example, I have friend who has a government job that requires use of a private vpn to access government assets. The laptop when connected to the vpn network still queries the routers dns server from time to time for innocent queries such as these ntp server queries.)

One way to quickly find out who's device it could be is to use skynet to manually ban that IP address from your network. (It should be noted that doing such is a bit on the extreme side for what appears to be innocent client queries).
I installed Skynet today and banned this IP. I will watch.
 
I installed Skynet today and banned this IP. I will watch.
Better safe than sorry... though unlikely someone nefarious is targeting you.
 
Better safe than sorry... though unlikely someone nefarious is targeting you.
I agree, the queries look innocent enough. The real question should be which network (remote) client is producing the traffic. I consider that to be more important. Also, could there be an undiscovered flaw in adguardhomes client identification feature? That question has yet to be answered.
 
I agree, the queries look innocent enough. The real question should be which network (remote) client is producing the traffic. I consider that to be more important. Also, could there be an undiscovered flaw in adguardhomes client identification feature? That question has yet to be answered.
Yesterday I cleared the AGH statistics. From the moment of ban IP 11.41.108.58 until today, there were no queris from him. But today the requests appeared again. The first one was when I came home and turned on the Wi-Fi on my phone, the second after 8 minutes, and there are still no more. This is despite the fact that this IP is banned in Skynet.

P.S.: I began to suspect that the Adguard application on my phone was somehow to blame, constantly running in the background to filter ads. I'll try turning it off for a week and see.
 

Attachments

  • 1.jpg
    1.jpg
    31.4 KB · Views: 65
Last edited:
Yesterday I cleared the AGH statistics. From the moment of ban IP 11.41.108.58 until today, there were no queris from him. But today the requests appeared again. The first one was when I came home and turned on the Wi-Fi on my phone, the second after 8 minutes, and there are still no more. This is despite the fact that this IP is banned in Skynet.

P.S.: I began to suspect that the Adguard application on my phone was somehow to blame, constantly running in the background to filter ads. I'll try turning it off for a week and see.

Not sure if you ran an IP lookup, but 11.41.108.58 is part of the DoD... or Department of Defense... well, that's worrysome. :(

1683986265945.png
 
it looks like DoD Home is already in AsusWRT

This miscommunication between agencies is only wasting tax money. We got it covered already. Me, Viktor (the person you know as Viktor) and someone over the rainbow even we know very little about. Last time I asked questions about this person I was moved to Guam and given gate security job.
 
This miscommunication between agencies is only wasting tax money. We got it covered already. Me, Viktor (the person you know as Viktor) and someone over the rainbow even we know very little about. Last time I asked questions about this person I was moved to Guam and given gate security job.
I don't remember, it seems to me that my memory has already been erased. I'm going to go put on my tinfoil hat... and wrap some foil around the router, just in case.
 
I don't remember, it seems to me that my memory has already been erased. I'm going to go put on my tinfoil hat... and wrap some foil around the router, just in case.
NO! DON'T!!! You will extend it's range!!!
 
This miscommunication between agencies is only wasting tax money. We got it covered already. Me, Viktor (the person you know as Viktor) and someone over the rainbow even we know very little about. Last time I asked questions about this person I was moved to Guam and given gate security job.
This is quickly turning into a "Spot the Fed" contest! Lol
 
This is the new guy from the 4th floor East Wing who was assigned to UFO crash site investigation, remember? Apparently they flashed him after.
 
Status
Not open for further replies.

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top