search

AdguardTeam / AdGuardHome

Network-wide ads & trackers blocking DNS server
https://adguard.com/adguard-home.html
GNU General Public License v3.0
24.67k stars 1.78k forks source link

AdGuardHome doesn't display ECS (EDNS) requester IP in webui, uses client IP instead #3978

Closed gtxaspec closed 2 years ago

gtxaspec commented 2 years ago

Issue Details

Expected Behavior

As AdGuardHome receives a DNS request, it should extract the ECS data (requester IP) and use this in the WebUI logs instead of using the client IP.

Actual Behavior

AdGuard ignores the ECS requesters IP and uses the client IP to display in the WebUI.

In the log below, you can see that the client IP ( [debug] client ip: 200x:xxx:xxxd::50 ) is used, not the ECS requester ( [debug] Passing through ECS data: 10.xx.1.17/32 )

When you have a router that has several clients behind it, the logs only show the client IP (router's IP), not the actual requesting client's IP even though the requester's information is provided using ECS/EDNS data to AdGuard. This would be useful in a household network or a small office to see what the IP of the actual requesting device is.

Screenshots

InkedScreenshot 2021-12-21 233725_LI

Additional Information

logs:

2021/12/21 23:19:42.096828 1336#5274 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).udpHandlePacket(): Start handling new UDP packet from [200x:xxx:xxxd::50]:51621
2021/12/21 23:19:42.096942 1336#5274 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): IN: ;; opcode: QUERY, status: NOERROR, id: 31629
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;android.com.   IN   A

;; ADDITIONAL SECTION:

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: ; udp: 512
; LOCAL OPT: 65001:0x100ba9600318
; SUBNET: 10.25.1.17/32/0

2021/12/21 23:19:42.097026 1336#5274 [debug] hosts container: handling the request
2021/12/21 23:19:42.097095 1336#5274 [debug] Passing through ECS data: 10.xx.1.17/32
2021/12/21 23:19:42.097138 1336#5274 [debug] serving response from subnet cache
2021/12/21 23:19:42.097174 1336#5274 [debug] DNSFwd: Checking record A (142.250.188.228) for android.com.
2021/12/21 23:19:42.097214 1336#5274 [debug] ipset: starting processing
2021/12/21 23:19:42.097241 1336#5274 [debug] ipset: added 0 new ipset entries
2021/12/21 23:19:42.097268 1336#5274 [debug] client ip: 200x:xxx:xxxd::50
2021/12/21 23:19:42.097315 1336#5274 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): OUT: ;; opcode: QUERY, status: NOERROR, id: 31629
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;android.com.   IN   A

;; ANSWER SECTION:
android.com.    2265    IN  A   142.250.188.228

;; ADDITIONAL SECTION:

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: ; udp: 512
jumpsmm7 commented 2 years ago

Issue Details

* **Version of AdGuard Home server:**
  Latest Master

* **How did you install AdGuard Home:**
  from edge installer on github

* **How did you setup DNS configuration:**
  openwrt running dnsmasq > dedicated adguard server

* **If it's a router or IoT, please write device model:**
  dedicated server

* **CPU architecture:**
  arm64

* **Operating system and version:**
  Debian 11

Expected Behavior

As AdGuardHome receives a DNS request, it should extract the ECS data (requester IP) and use this in the WebUI logs instead of using the client IP.

Actual Behavior

AdGuard ignores the ECS requesters IP and uses the client IP to display in the WebUI.

In the log below, you can see that the client IP ( [debug] client ip: 200x:xxx:xxxd::50 ) is used, not the ECS requester ( [debug] Passing through ECS data: 10.xx.1.17/32 )

When you have a router that has several clients behind it, the logs only show the client IP (router's IP), not the actual requesting client's IP even though the requester's information is provided using ECS/EDNS data to AdGuard. This would be useful in a household network or a small office to see what the IP of the actual requesting device is.

Screenshots

InkedScreenshot 2021-12-21 233725_LI

Additional Information

logs:

2021/12/21 23:19:42.096828 1336#5274 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).udpHandlePacket(): Start handling new UDP packet from [200x:xxx:xxxd::50]:51621
2021/12/21 23:19:42.096942 1336#5274 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): IN: ;; opcode: QUERY, status: NOERROR, id: 31629
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;android.com. IN   A

;; ADDITIONAL SECTION:

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: ; udp: 512
; LOCAL OPT: 65001:0x100ba9600318
; SUBNET: 10.25.1.17/32/0

2021/12/21 23:19:42.097026 1336#5274 [debug] hosts container: handling the request
2021/12/21 23:19:42.097095 1336#5274 [debug] Passing through ECS data: 10.xx.1.17/32
2021/12/21 23:19:42.097138 1336#5274 [debug] serving response from subnet cache
2021/12/21 23:19:42.097174 1336#5274 [debug] DNSFwd: Checking record A (142.250.188.228) for android.com.
2021/12/21 23:19:42.097214 1336#5274 [debug] ipset: starting processing
2021/12/21 23:19:42.097241 1336#5274 [debug] ipset: added 0 new ipset entries
2021/12/21 23:19:42.097268 1336#5274 [debug] client ip: 200x:xxx:xxxd::50
2021/12/21 23:19:42.097315 1336#5274 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): OUT: ;; opcode: QUERY, status: NOERROR, id: 31629
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;android.com. IN   A

;; ANSWER SECTION:
android.com.  2265    IN  A   142.250.188.228

;; ADDITIONAL SECTION:

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: ; udp: 512

I have noticed this same issue as well. While AdguardHome is able adequately parse the client IP information with ECS data, it does not properly reflect the client identification information in the WEBUI, thus filter rules are not able to be adequately defined(or applied) per client identified in this manner. As mentioned by the OP, this can be troublesome for one not only wanting to monitor traffic or define rules for clients identified in this manner, but also provides issues for people with multiple interfaces, or VLANs on the same network destined for adguardhome.

agneevX commented 2 years ago

2021/12/21 23:19:42.097095 1336#5274 [debug] Passing through ECS data: 10.xx.1.17/32

I think AGH should not send private IP ranges as ECS data to resolvers.

jumpsmm7 commented 2 years ago

2021/12/21 23:19:42.097095 1336#5274 [debug] Passing through ECS data: 10.xx.1.17/32

I think AGH should not send private IP ranges as ECS data to resolvers.

We are talking two different things. He is not saying take the clients Private IP and pass it to the upstream resolvers. He is saying Locally identifying clients by the ECS data parsed from the clients information.

agneevX commented 2 years ago

I'm aware; its an observation.

gspannu commented 2 years ago

@ainar-g @EugeneOne1

It would be useful to add a boolean flag (in the yaml file) whether the ECS data or Client IP data should be used for display, rules, etc...

Something like client_ecs_data: true/ false

ainar-g commented 2 years ago

@gspannu, this issue is currently only about the UI. Using the ECS data to identify clients is another topic, and I'm not even sure if that can be done reliably, considering that clients can put any value there.

gspannu commented 2 years ago

@gspannu, this issue is currently only about the UI. Using the ECS data to identify clients is another topic, and I'm not even sure if that can be done reliably, considering that clients can put any value there.

The reason for the request (and hopefully I have not misunderstood)...

I have AdGuard Home running in the cloud. All encrypted and supports DoT and DoH clients. iOS devices well protected as I am using .mobileconfig and have specified individual clients (DoH)

I also use the same AGH instance from my home router (Asus router running Merlin)

All my queries from router to AGH instance are also running DoT... and herein lies the issue.

AGH Instance detects all queries from the router (public IP) as originating from the router rather than the underlying client IPs (192.168.x.x)

I have set the flags add-mac and add-subnet=32 in my dnsmasq settings in the router, but it seems that AGH ignores this data when receiving DoH/DoT request from the client and only uses the ClientID field.

Is there any way where I can have AGH identify the underlying clients (192.168.x.x) and still make a DoH/DoT DNS request to the AGH instance?

ainar-g commented 2 years ago

@gspannu, this is not really the right place for such questions; we strive to keep them in the Discussions.

ClientID should be enough to identify the client, and if you want to identify them by IP over DoH, you should set the appropriate headers in your HTTP proxy and use the trusted_proxies parameter. If that doesn't work for you, please post a new discussion about that. Thanks.

EugeneOne1 commented 2 years ago

@gtxaspec, @gspannu, hello again and sorry for the delay. We've added the ECS into the request details section of query log entries. It's already available in the latest edge build. Could you please install it and check if it works properly?

jumpsmm7 commented 2 years ago

@EugeneOne1

@gtxaspec, @gspannu, hello again and sorry for the delay. We've added the ECS into the request details section of query log entries. It's already available in the latest edge build. Could you please install it and check if it works properly?

I will test for you shortly as well. Thank you for this brilliant addition!

gtxaspec commented 2 years ago

@EugeneOne1

Latest edge, i can confirm that the ECS details do show up under the "Request details" of the user interface.

Will the "Client details" be updated with this information as well,in the future? thank you

EugeneOne1 commented 2 years ago

@gtxaspec, we've got a couple of ECS-related issues already (e.g. #1727, #2514). Do you mean duplicating this info to the "Client details" of the same query log entry?

So far, it seems the issue may be closed for now. Please consider opening a new one if it isn't yet.

jojost1 commented 2 years ago

@gtxaspec

Latest edge, i can confirm that the ECS details do show up under the "Request details" of the user interface.

Would it be possible to share a screenshot here showing how the UI displays it? I'm building support for ECS display inside AdGuard Home Remote and I can't test this myself. Thanks!

gspannu commented 2 years ago

@gtxaspec

Latest edge, i can confirm that the ECS details do show up under the "Request details" of the user interface.

Would it be possible to share a screenshot here showing how the UI displays it? I'm building support for ECS display inside AdGuard Home Remote and I can't test this myself. Thanks!

Screenshot