Dns intercept logging
-
I'm running an adguard home dns server on its own vlan/subnet. Pfsense unbound is configured in forwarding mode, with the ip of ADH as ths dns server. Pfsense DHCP server assigns ADH ip for dns to all clients (lan/vlan)
Network config consists LAN, VLAN3, VLAN4, VLAN5, and 2 others. The 2 others are NOT subject to intercept.
A network interface group is configured to include LAN and VLAN3...5.
Port forward rule is configured as follows:
Local_networks = LAN, VLAN3...5
dns_server = alias ip of adguard home
dns_alias = alias for ports 53, 853The intercept works correctly. I tried enabling logging on the respective firewall rule (shows up as local_networks under Firewall/Rules) but that ends up logging all dns queries, even those not intercepted.
My understanding for this because of order of priority - interface group rules are processed before interface rules. So even though this rule is linked to a port forward, it's still an interface group rule.
Is there another way of logging port forwards?
-
It's been a few weeks and no replies :(.
Had to think out of the box for this one because of the way rules are processed. The solution was to add another IP to the dns server. It now listens on 2 different ip's on the same subnet.
The first ip (x.y.z.100) is the standard dns server provided by dhcp to all clients (and configured manually for static clients). Second ip (x.y.z.101) is the destination for the port forward. This one has logging enabled.
By having different IP's, there's now 2 distinct firewall rules so no overlap in matching. The resulting firewall log is not ideal, it just shows the source ip and second dns server ip (x.y.z.101).
The original goal was to see where a particular client was trying to reach out to for its dns. Short of having some logging capability on port forwards themselves, this is as good as it gets. For further detail I can run a tcpdump on the client and observe output.
-
I've come up with a rather clunky work around. In part, due to the way rules processing order works, the firewall rule generated by the DNAT is also active when no interception is taking place. Setting that rule to log logs everything.
The work around involved assigning 2 ip's to the dns server (x.y.100.2 initial, and x.y.100.3 secondary). DHCP is still configured to handout x.y.100.2 to all clients. Dns server configured to listen on 0.0.0.0.
Note there are 2 dnats, and order does matter. I have a few amz tablets that hardcode 8.8.8.8 into the dns no matter what dhcp is or even if set static. To work around this an alias of these ip's is defined and used in the first rule. The matching firewall rule has no logging enabled. This still intercepts the requests but makes no log entry.
The second rule is the main one. If dns traffic is not going to x.y.100.2, then redirect to x.y.100.3. Logging enabled in the firewall for this one.
Again, order is very important.
This fixes half of the problem. I can now see which IP's disrespected defined dns setting.
What I don't see is what the original target was, only the dnat'd target.
To fix this requires running tcpdump either on the client in question (if possible), or on the firewall itself.
tcpdump -ntttti vtnet1 -p -U '((not (src 10.10.100.2)) and (not dst 10.10.100.2 and (port 53 or port 853)))' -AThis is only valid on a single interface (no -i any in freebsd). But basically captures any dns traffic on ports 53/853, udp/tcp, that's not coming from the dns server and not going to the dns server. Output looks like this.
``
17:19:06.250607 IP 10.10.1.141.49237 > 1.2.3.4.53: 174+ A? google.com. (28)
E..8oQ@.@..........U.5.$...............google.com.....
17:19:06.251023 IP 1.2.3.4.53 > 10.10.1.141.49237: 174 1/0/0 A 142.250.190.142 (44)
E..H..@.?.B........5.U.4...............google.com..............P......
``
10.10.1.141 client
1.2.3.4 rogue dns serverThis work around does achieve the desired result, but it's reactionary. First have to periodically review firewall log to see if any intercept traffic got captured. If so then run tcpdump and hope the traffic repeats.
The other option is run tmux on a server with a ssh'd session into the firewall with the tcpdump command ongoing. Not sure how viable this is long term. Still unclear why this functionality hasn't been added by now. There's a number of threads about it here, reddit. Even the opnsense has port forward logging option.
-
In reviewing the same concern in opnsense, it appears commits were made some 3 years back to enable this exact functionality.
https://github.com/opnsense/core/issues/5005
Any chance of this getting ported to pfsense?