Right, it definitely has got something to do with shorewall.
nmap 192.168.1.249
Starting Nmap 7.92 ( https://nmap.org ) at 2022-04-08 21:34 BST
Nmap scan report for 192.168.1.249
Host is up (0.0097s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
If I run shorewall clear, then the DNS queries work. When I re-enable the firewall, the DNS queries stop.
I only have 1 interface which is br0 and it is assigned the Green LAN.
What Shorewall rule(s) do I need to add to make this work?
Although that sample shows for OUT traffic, there are DROPs for IN traffic to the PiHole.
Which also begs the question (which maybe a seperate topic - why the crackers are there a lot of IP Addresses on the Public Internet trying to communicate with my PiHole when its located behind two (2) NATted routers with no port forwarding to it and there is no DMZ either? This suddenly raises quite a large security concern - 1652 attempts since 5th April and this isn;t even production ready and been offline half the time which is super concerning.
This PiHole will definitely need to be behind a firewall.
Thereâs probably no hacker or botnet out in the wild trying to access YOUR PI-Hole / NethServerâŠ
24x7x365 there are hackers / script kiddies / russians / chinese and others (Choose what term you prefer) out in the wild, using port-scanners and other tools to âprobeâ for vulnerabilities. Any IP in use can be affected, this usually depends from where the attack / probe is comming from, and how good are the capabilities of the potential attackers.
The only difference between you and a typical home user is that you actually look at the logs of the firewall box, most others donât even know they exist.
Think of a city house or appartment. A potential burglar will first ring on the bell.
If anyone answers, theyâll put some BS storyâŠ
If no one answers, they try to see if the place is locked, by trying the door handle / knobâŠ
If itâs not locked, itâs what they call âan easy jobââŠ
â And these are the logs youâre seeingâŠ
Just placing a placebo camera (fake) reduces door knob attacks by around 80%.
Just âtestingâ the door knob doesnât mean that you must install a âzapperâ system on the doorknob.
But seeing the faces on the (hidden) camera after being zapped might be amusingâŠ
Iâm still fighting with reproducing your issue, I installed the same packages, rebooted, reset pihole to aqua, aeria and back to macvlan without success. So I need to ask some more questionsâŠ
Is the aeria network still enabled? We donât need it so letâs disable it to avoid issues.
[root@testserver2 ~]# docker plugin ls
ID NAME DESCRIPTION ENABLED
2f1febf7f90f devplayer0/net-dhcp:latest Docker host bridge DHCP networking false
To disable:
docker plugin disable 2f1febf7f90f
Letâs check the complete structure:
find /etc/e-smith/templates-custom/
I donât get these entries at all.
My entries look like this (192.168.1.65 is the pihole, I changed pihole dns servers to 1.1.1.1 and 9.9.9.9):
[root@testserver2 ~]# ip a | grep macvlan
20: macvlan0@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 192.168.1.64/27 scope global macvlan0
[root@testserver2 ~]# brctl show
bridge name bridge id STP enabled interfaces
aqua0 8000.02426f9c5390 no veth974e02f
br0 8000.b2e69f14be62 no eth0
vb-nsdc
docker0 8000.0242a9e3974c no
[root@testserver2 ~]# shorewall show | grep macvlan
50 6197 ~comb0 all -- macvlan+ * 0.0.0.0/0 0.0.0.0/0
5 260 macvl_frwd all -- macvlan+ * 0.0.0.0/0 0.0.0.0/0
4 646 ACCEPT all -- * macvlan+ 0.0.0.0/0 0.0.0.0/0
0 0 aqua2macvl all -- * macvlan+ 0.0.0.0/0 0.0.0.0/0
0 0 net2macvl all -- * macvlan+ 0.0.0.0/0 0.0.0.0/0
0 0 dock2macvl all -- * macvlan+ 0.0.0.0/0 0.0.0.0/0
0 0 loc2macvl all -- * macvlan+ 0.0.0.0/0 0.0.0.0/0
0 0 sfilter all -- * macvlan+ 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 sfilter all -- * macvlan+ 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 sfilter all -- * macvlan+ 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 sfilter all -- * macvlan+ 0.0.0.0/0 0.0.0.0/0 [goto]
Maybe it helps to remove the containers config files and data (which also resets to container to default settings and removes the stats data) and the macvlan network?
Destroy container:
pihole destroy
Remove data::
rm -rf /var/lib/pihole/*
Get ID of macvlan network:
docker network ls
Remove macvlan network, use ID of previous output:
And that appears to have fixed it @mrmarkuz , thank you for all of your help and patience. THis has been a fairly difficult case to troubleshoot.
Weirdly enough, and I don;t know why this has happened, PiHole only showing the server showing as making the DNS query and not the different devices.
So although I find that a bit confusing as I expect the macVlan to provide the ability to show which device made the DNS query, I am at a point where I am happy to go with that if needs be.
As you are using AD and the pihole doesnât know about your AD devices you may need to enable conditional forwarding for your domain in pihole Settings/DNS (scroll down to bottom):
