The issue I am facing:
Server crashes spikes in DNS use, generally once a day:
Not at a consistent time, and not on consistent users.
Details about my system:
Rp5 + NVME server, Business network behind Robustel r5020 router - RPi directly into ethernet port, all other access behind 3 Access points
What I have changed since installing Pi-hole:
Switched on DHCP, ported over static IPs list from R5020
Debug log:
The devs are almost certainly going to need a debug log to help out.
Tools/Generate debug log (copy/paste the token ID it gives when the debug tool completes, make sure you tell it to upload the log for you).
I think I'm pinning this down to a few malicious connections (we have coffee shop, and offices above).
Folk upstairs, on their lunch breaks spamming our wifi connection to get past the blockers on their corporate LAN? Maybe.
May not be the correct way to handle this, but I've attempted to block specific MACs when they are abusive by adding them to a block group - with a regex rule .* and attempted to block the MAC on the APs where available/possible. One in particular seems to be spamming PTR requests, aimed at amazon servers - and some (this one in particular) are masking their MACS - which is weird, and I thought difficult to impossible.
Any other ideas, when I'll have to identify each spammer individually?
Tracking DNS requests to an individual client on a public network offering without that client's explicit prior consent may be considered illegal, depending on the legislation in your country of residence.
Are you talking about actually masking the MAC, or about MAC address randomisation?
MAC addresses have a same-link only visibility, so masking a MAC is expected to happen for any device connecting via some L3 switching equipment.
Also, most modern OSs will randomise their MAC address upon connecting to a new (wifi) network by default, potentially upon any reconnect.
Lunch breaks with lots of clients (re)joining your network could nicely explain sudden spikes, ebbing down once the break is over.
By itself, that would not indicate any malicious intent.
Thanks for the warning - though any tracking here is a side effect of enabling DHCP on pihole as my router(s) were struggling to cope with the volume of requests, just as pihole does - and has been crashing daily until the worst offenders were individually throttled on a daily basis.
I can't see any way to prevent this without individually rate limiting clients, and blocking repeat offenders. This requires a certain loss of anonymity - just like when a client connects to the network (without using a VPN) they necessarily hand over a certain amount of information.
Obviously watching the DHCP leases and volume of requests per client is unsustainable (and as you say, potentially unethical) so really, as I said in the original post, I'm looking for suggestions to manage this and keep my network functioning whilst still offering WiFi to customers in my cafe.
Is there a better way using pihole here, or am I better looking for something like fail2ban (that I use on my public facing server to prevent malicious usage of my website). Is there even such a thing for LAN network protection?
Tracking a client's DNS requests is possible if that client is using Pi-hole for DNS, regardless where the service announcing Pi-hole resides.
Offering a public wifi may also require you to monitor client activities under some legislations, and to strike the balance, prior consent could be key (e.g. by showing a banner that informs a client that their activities are to be tracked if they use your service).
But don't take my word for it, those are just hints - really, as a business, you want to seek professional legal advice on proper precautions for your country.
In the event of a real crash, Pi-hole would log that to /var/log/FTL.log.
So far, you have not shared any evidence of an actual crash.
On the contrary, your screenshots demonstrate Pi-hole's DNS server to have been operational all the time, handling requests before, during and after your peaks.
It is thus unclear what your issue is.
How did you achieve that?
Pi-hole's own rate limit operates on the overall number of DNS requests per time interval, i.e. you can't rate limit individual clients.
In case your issue would be with excessive DNS requests, blocking a client completely may have an adverse effect, as that may prompt even more (misbehaving) client software to excessively repeat DNS requests for blocked domains.
Or could your issue perhaps be with client DHCP broadcasts rather than DNS?
E.g. you mention
Above does not disclose which requests you'd be referring to (DHCP, DNS, HTTP, ...)?
Please try to explain your actual issue, and provide additional relevant details.
Answering my previous question could also help.
Thankyou, that is useful.
This is also useful- and would explain why the whole LAN appears to lose connectivity when the spamming incidents occur, rather than specific users unable to connect, which was my assumed functionality.
On the first few days I ran pihole as my DHCP server, The RPI5 on which Pihole is running had needed to be restarted manually, as it became unresponsive to SSH requests, which is impractical as I'm not always on hand to resolve the issue. I originally implemented pihole to try and get a handle on what was causing my network connectivity issues on a daily basis - and asked here for some assistance in identifying them, as such I don't know specifically what is causing them, or which requests are the culprit. Now I know which logs you need specifically, i have retrieved them - they don't go back far enough to the crashes, so I will monitor from now on. Is there an ERROR level in particular I am looking for?
In the meantime, I would appreciate any insight you/the forum can offer in order to stabilise this particular implementation, in what is admittedly a fringe use case.
If you are reading this - then I have found this helpful, for example:
Is proving easier then propagating a block list around several routers / aps / when clients shift to another access point.
After a fixed 12 or 24 hours or so?
Thats a common one if the Pi isnt configured with a manual static IP but instead with one thats acquired automatically via DHCP.
Part of the switch procedure is to disable the routers DHCP service.
So after 12 or 24 hours or so, the current active DHCP lease on the Pi expires (the one from the router) and the Pi loses its IP details resulting in that you cant connect anymore.
And a DHCP server (the Pi) cant supply itself with a unicast IP address.
$ sudo pihole-FTL dhcp-discover
Scanning all your interfaces for DHCP servers
[..]
lease-time: 86400 ( 1d )
Have a look at below solution:
How would you be able to tell which MAC to accept and which one to ignore?
Why would denying a specific MAC be helpful?
How does this address your issue?
A client that would be denied a DHCP lease would just keep searching for DHCP servers, convoluting your network with additional DHCP broadcasts. When it finally gives up, it will assign itself a link-local IPv4.
Also note that DHCP is strictly IPv4, so that client may yet acquire a regular IPv6 address to join your network. And furthermore, denying a specific MAC address would be pointless if the client uses aforementioned MAC address randomisation.
I don't see much room for that speculation, as you've stated that your issue actually predates Pi-hole:
Also, the amount of queries shown in your screenshots are not enough to guarantee that Pi-hole's default rate limit would kick in. Furthermore, Pi-hole's UI would have explicitly informed you if a rate limit would have been triggered, and it would have applied that to specific clients, not to your entire network.
As you didn't report that to have happened, I doubt that your observation would be tied to DNS rate limiting.
I don't see how we could make much progress if you keep ignoring my questions, offering your own speculations instead.
Whatever your issue is, as you state that the issue has been manifesting itself before you installed Pi-hole, I am starting to doubt that Pi-hole has a part in it.
I am surprised you didn't consider this problem before you set up your network.
For years in my humble domestic setup wifi access is either private for family or guest access that doesn't touch my network or any other guest user. Guest access provides internet web only with access to defined DNS servers only so there is no getting round my family friendly defined DNS in DHCP and no P2P. I don't want guests filling up the logs on my piholes.
All this is done using dd-wrt running on a cheap domestic router.
Thanks All, I won't take up any more of your time.