The issue I am facing: I am trying to setup a Geo Blocking service that resolves a DNS request and then matches that IP to a Geo Blocking service (Specifically Maxmind). The way Im setting this up is with a pcap dump file and according to the Pihole documentation ( Packet dump - Pi-hole documentation ) the settings in FTL should be:
dumpfile=/etc/pihole/dump.pcap
dumpmask=0x00ff
But when I start FTL I receive this error:
Mar 24 23:51:26 pihole pihole-FTL\[54620\]: dnsmasq: cannot access /etc/pihole/dump.pcap: No error information
Mar 24 23:51:26 pihole dnsmasq\[54620\]: cannot access /etc/pihole/dump.pcap: No error information
Mar 24 23:51:26 pihole dnsmasq\[54620\]: FAILED to start up
I have set the ownership as pihole:pihole / dnsmasq:root / root:root with chmod set at 777 and still received the above error.
Details about my system: I am running Pihole on Ubuntu 22.04 inside a VM. It runs flawlessly.
What I have changed since installing Pi-hole: Nothing. I am simply trying to understand how exactly to set correctly a pcap dump file in FTL so that FTL can start without errors.
Please generate a debug log, upload it and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
In trying to get the pcap dump file to work I found that setting it to be located in /tmp (/tmp/dns-geo.pcap) and chown to dnsmasq:root that it worked but I dont like it being in /tmp.
Why do you employ a dump file here?
If your service makes the DNS request, why don't you use the IP addresses from the DNS reply for that request straight away?
Thats literally what I said Im doing: “The issue I am facing: I am trying to setup a Geo Blocking service that resolves a DNS request and then matches that IP to a Geo Blocking service (Specifically Maxmind).”
The mechanism Im looking to use is the included PCAP service that FTL supposedly supports. My backup to doing this is through a regular TCPDUMP but done as a service outside/alongside FTL.
With all of that said, again this isnt really an answer to the problem I am having. I appreciate the response.
I can't see how reading a pcap file would literally be the same as using a DNS reply directly.
Reading the pcap file would disregard that reply, producing additional I/O to read raw data from a 0xFFFF dump file instead, which on top of that would require you to scan the entire DNS conversation history, differentiating the replies for the requests you are interested in from all other DNS requests Pi-hole has handled.
That indirect approach seems far less effective than using the very DNS reply returned by Pi-hole specifically for the request your service has issued.
PCAPs are literally right off the NIC. I dont see how you can make a more informed unfiltered analysis than with a PCAP.
”Reading the pcap file would disregard that reply, producing additional I/O to read raw data from a 0xFFFF dump file instead, which on top of that would require you to scan the entire DNS conversation history, differentiating the replies for the requests you are interested in from all other DNS requests Pi-hole has handled.” - Exactly? I want an unfiltered packet capture to firmly identify the destination country so that I can then Deny that connection (or allow it if its based in the US) BEFORE it gets to FTL for any kind of analysis. I dont want there to be confusion in the GEO blocking that takes precedence.
@whoa I think this is the actual solution you are looking for instead of using a .pcap file which is meant for useage with WireShark and not something you constantly “look into” as if it were a SQLite database so to speak
That sounds like you want to manipulate the DNS reply that Pi-hole itself receives, rather than matching IPs from the reply Pi-hole issues?
How does that sound like I want to manipulate the DNS reply? I want GEO-Blocking to take precedence of the connection until the Geo-Blocking policy approves or denies the connection entirely.
The dump file contains copies of network packets, i.e. for Pi-hole to dump a reply as provided by an upstream, Pi-hole would already have received it.
As I stated from the beginning , the point to the packet capture is that it is the mechanism to take the connection/packet information. The Geo-Blocking service will be constantly analyzing the packet capture to resolve the destination and then apply a Geo-Blocking policy to it. I mentioned that it works along-side FTL, but if the policy is a deny, it will reset the entire connection. There wont be anything for Pi-Hole to do when that happens. Yes, it may (possibly not depending on how fast the Geo-Blocking service runs) do some DNS processing but if theres a TCP connection reset, it will stop its processing at that point because the connection has been reset.
I think this is the actual solution you are looking for instead of using a .pcap file which is meant for useage with WireShark and not something you constantly “look into” as if it were a SQLite database so to speak
I’m missing the solution… The problem is (and always has been) that the supported FTL packet capture process is not working. Help me understand where the solution is?
This may be a misunderstaning.
I'm beginning to think your service is not sending DNS requests itself, despite you answering my initial question "If your service makes the DNS request, why don't you use the IP addresses from the DNS reply for that request straight away?" with "That's literally what I said I'm doing".
Would the following be adequate to describe your intention with probably less ambiguity?
"I am trying to setup a Geo Blocking service that monitors DNS replies for IP addresses, and then matches those IPs to a Geo Blocking service, in order to reset any client connections to IPs from certain locations".
Would the following be adequate to describe your intention with probably less ambiguity?
"I am trying to setup a Geo Blocking service that monitors DNS replies for IP addresses, and then matches those IPs to a Geo Blocking service, in order to reset any client connections to IPs from certain locations"
Im curious. What do you think FTL does when a DNS request results in a match with a list that is a blocklist? I dont need an answer here…so I am not curious after all.
My interest in this thread has absolutely nothing to do with how my Geo-Blocking service works. To get this thread back on track, I would really like to know how to get the FTL PCAP process to work correctly. From this point forward, please do not talk about Geo-Blocking. It has nothing to do with what I am asking about.
Do you have something that would name the file dns-geo.pcap when all of the config files (and the underlying dnsmasq are set to dump.pcap?
Also, setting a file as 777 makes it executable and not a great idea. At the least make it 666 so the execute bit isn't set.
Edit: Check your dumpmask as well, it looks like you might be interpreting that to be the file mask? Per the dnsmasq manpage:
--dumpfile=<path/to/file>
Specify the location of a pcap-format file which dnsmasq uses to dump copies of network packets for debugging purposes. If the file exists when dnsmasq starts, it is not deleted; new packets are added to the end. The file may be a named-pipe which Wireshark is listening to.
--dumpmask=
Specify which types of packets should be added to the dumpfile. The argument should be the OR of the bitmasks for each type of packet to be dumped: it can be specified in hex by preceding the number with 0x in the normal way. Each time a packet is written to the dumpfile, dnsmasq logs the packet sequence and the mask representing its type. The current types are: 0x0001 - DNS queries from clients, 0x0002 DNS replies to clients, 0x0004 - DNS queries to upstream, 0x0008 - DNS replies from upstream, 0x0010 - queries send upstream for DNSSEC validation, 0x0020 - replies to queries for DNSSEC validation, 0x0040 - replies to client queries which fail DNSSEC validation, 0x0080 replies to queries for DNSSEC validation which fail validation, 0x1000 - DHCPv4, 0x2000 - DHCPv6, 0x4000 - Router advertisement, 0x8000 - TFTP.
