PiHole Rasbian RP4b Blocked Traffic

Security Firewall Rules
1

As Bernhard mentioned in an adjacent thread, I have 2 adjacent logical networks on Green, as you can see in the image. I am now toying around with PiHole.

I took a Raspberry Pi 4b, installed Rasbian latest revision on it, installed PiHole through scripts provided on their website and assigned it to a static IP address in my 172.x.x.165/32 network with the Green Interface 172.x.x.1 being the gateway, and plugged it into the switch just above the red box on the right in the below image.

image
image609Ă—778 50.2 KB

Here is the trippy thing. I can get to PiHole from any computer in the 172.x.x.0/24 network, at its Web UI http://ip/admin and it loads, browses and acts absolutely normal. Fully functional might I add… except for 1 thing.

When I jump on any other computer in my logical 10.x.x.0/24 network segment, I can’t hit it with SSH, ICMP, HTTP or anything else successfully.

Now to address that piece. I run tcpdump -XXnni any on the IPFire SSH and I can see inbound traffic heading to the PiHole. I then jump to SSH on PiHole at 172.x.x.165 and I can see the traffic arriving…however the return traffic never crosses IPFire on the way back across the network segment. I can say I have a ton of traffic crossing that segment successfully, but apparently I am missing something basic here. I have been about 8 straight hours with hands on keyboard, ssh, and pondering wth may be going on with this.

The Options in the IPFire firewall can be confusing.

Since my logical network on Wifi is upstream from my switch, I assume something may be getting blocked on its way back to its origin, but I had thought requested traffic from point A to B, if it makes it, would be stateful on the way back.

I can also say that IPFire, even though logically I am still on the Green Network, I am not fully in Green or my entry upstream wouldn’t be black in the color scheme. Not sure on that one, but thought I would mention it.

As only an example of color scheme, this is what happens when I add my 10.x.x.x network segment in, although technically logical.

image
image1139Ă—69 10.4 KB

Any ideas?

Eric

2

Your AP does some sort of NAT ( connecting the 172.xx.yy.0/24 and the 10.zz.aa.0/24 networks ) and maybe some firewalling also.

Without a exact description of your setup and configuration ( all devices: IPFire, AP, Raspberry, switch ) it is difficult, to help you really.

3

I’m going to take a guess and say you’re using pi-hole on 172.X.X.240 to run the 10.x.x.x subnet. I think that would mean you’d have to write some routing rules on the pi-hole, and I don’t know if pi-hole can do that.

I run pi-hole (DHCP off) on green in a Debian virtualbox on my file server. I use a 2nd fritzbox (DHCP off) on green (behind the IPFire box) for WIFI. IPFire handles all DHCP. DNS 1 on IPFire points to the pi-hole. I Use the IPFire DNS security rules as listed in the how-to, and also have DNSCrypt running on the pi-hole box.

This keeps all devices in one green subnet. The only Firewall or Static route rule I need is to get to the WAN facing Fritzbox, I think.

I do this because I use a proxy forward to my commercial VPN service, so no devices need a VPN client, just an automatic detection (WPAD) or a manual entry to the IPFire if WPAD doesn’t work to the IPFire web proxy. This rig works well for what I do. Pi-hole stops a lot of ads, and having the VPN in the web proxy is great. My VPN service has a recommended server picker, so I run that and plug the recommended address into the proxy. Any device then (I have Linux, Android, Mac and Windows) goes seamlessly and without a local client through the VPN.

The second Fritzbox makes WIFI on the green LAN easy to integrate. You could always run a blue on IPFire or turn guest access on the Fritzbox if you wanted WIFI with no LAN access.

1 Like
4

Why did you set it up like this? There is no real security benefit if everything is connected to GREEN anyway. Instead, you end up with cascaded NATs which is generally a bad idea.
I’d suggest you disable the second DHCP and merge everything into one network managed by IPFire.

2 Likes
5

You correct. There is no security benefit to me segregating 2 logical networks the way I have done it. I wasn’t aiming at security for that setup, but I did it that way so I could chainlink my wifi and physical networks on Green. Eventually, I will potentially move Wifi to Blue, but that is for another day. Just saying, if security was my focus there, I would have introduced another inline Device between the switch and the WiFi access point. LOL

6

From any computer on 172.16.17.0/24, I can browse the PiHole GUI on http://IP/admin
From any computer on 172.16.17.0/24, I can SSH on port 22 and get full connection

From any computer on Wireless, I can not fully reach PiHole.
I have done linear packet captures on IPFire, Wireless Clients, and IPFire watching the flow of traffic.

When I am on a Wireless Client on the 10.10.90.0/24 network, I initiate SSH or browse the site http://IP/admin, I can see the following

tcpdump reviews
IPFire, shows Syn’s going to Destination
PiHole shows Syn’s arriving and Syn Ack’s being returned
IPFire shows Syn Ack’s being returned to Wireless Client
Wireless Client, traffic doesn’t arrive.

The WiFi AP has all Firewalling Disabled, and there is a Routing Table in Place

Destination Gateway Genmask Flags Metric Ref Use Type Iface
default 172.16.17.1 0.0.0.0 UG 0 0 0 WAN0 eth0
10.10.90.0 * 255.255.255.0 U 0 0 0 LAN br0
172.16.17.0 * 255.255.255.0 U 0 0 0 WAN0 eth0
172.16.17.1 * 255.255.255.255 UH 0 0 0 WAN0 eth0

image
image1273Ă—831 108 KB

I understanding IPFire is supposed to be a stateful firewall, to return traffic to the destination. I am further trying to figure out how to get a packet capture at the Ingress of the WiFi Router. Unfortunally, the vendor is currently closed and there is no documentation eluding to how this would be done. Although I can get SSH access into the device, it doesn’t appear that the developer added something as basic as tcpdump to the binaries. uggg…

Eric

7

Your traffic description shows the traffic PiHole --> WLAN is blocked by the AP.
This isn’t a problem of IPFire.

1 Like
8

We don’t know yet. That assumes it is leaving the IPFire Egress. I have yet to determine if the traffic is on the wire at the ingress of the WiFi AP on return traffic.

9

Where exactly? Have you tried setting routes to the 10.x.x.0 network on your Raspberry or IPFire?
I think this is a routing problem, not a firewall issue. Edit: At least not in the IPFire side, it shouldn’t be involved in the WLAN → Raspberry connection at all.

10

If carefully examined in my previous entry you will see details of what you noted. If there was a routing table issue, I wouldnt see traffic coming back out of IPFire in tcpdumps destined for the WiFi. I have a ton of connections destined for WiFi and they all work so IPfire is clearly aware of that network. I still am pending verification of my AP tcpdump. I will eve eventually get thst piece checked… heck, Bernhard may be right, but then again its all theory right now until I get that piece proved out.

Bernhard, is there a wiki page showing the Order of Operations for IPFire, so I can follow the packets through the device?

Eric

11

If the pictures of your installation are right, and interpreted right by me, Leo’s statement is right also. The communication between PiHole and wireless clients should flow in the green LAN ( I suppose ethernet ) only, without using IPFire. The switch in green distributes the packets to the appropriate attached devices (directly).
If this asumption doesn’t hold, your system is installed/configured other than you described/think.

12

Bernhard,

It took some magic to get tcpdump installed on my Wifi Router, which is logically in line on the Green network.

tcpdump -XXnn -w /var/tmp/diditcomeback.pcap

I captured all traffic and found “in-fact” that traffic is not making it back from IPFire.

image
image1914Ă—975 73.9 KB

Traffic Request Happens this way.

WiFi Client on 10.10.90.0/24 (In my current case “10.10.90.58” > Sends a SYN, and Passes through the Wireless Device > Passes Through Gigabit Switch > Passes Through the Green Interface Port on IPFire and Arrives at PiHole at 172.16.17.165, and PiHole Responds by Attempting to Send a SYN/ACK.

image
image1920Ă—887 124 KB

As we follow the traffic back upstream, we can see it hits the IPFire Interface, so we know it arrived, and is trying to communicate back toward the WiFi Router. Again, the traffic return shows a SYN/ACK, but never makes it from IPFire through a dumb Gigabit switch to the WiFi Router.

image
image1920Ă—1019 135 KB

It was previously suggested that it could have been a PAT or NAT issue on my Wifi Router, however I wanted to get you these screenshots so you could see for yourself that I wasn’t kidding. It is not a PAT or a NAT issue on the WiFi and has to be a problem with some type of configuration on the IPFire device, otherwise there would be an arrival of return traffic of at least a SYN/ACK from the return source of 172.16.17.165 (PiHole). I do this type of thing every day, so I am sure its not the problem that it was believed to be, but that does not rule out IPFire’s configuration.

The Cat 8 Cable is 8 foot long. If I need to get a 2 of my 4 foot cables and splice another dumb switch half way in, I can do that too. :stuck_out_tongue:

Thx,

Eric Spillman

13

Where did you capture the traffic?
The SYN ACKs are generated on PIHole and send to the green LAN, destination address 10.10.90.58. The only device knowing how the net 10.10.90.0/24 can be reached is your AP.

14

Bernard, if it doesn’t make it back to the AP leaving the IPFire, how can it then make a decision of where to route it. LOL… Do you see what I am saying?

15

I think i know where the confusion is coming from…

The Gigabit switch is a L2 MAC driven device. While it is true that both the Access point and the PiHole are hanging off the same switch, I am also moving from. 10.10.90.0/24 172.16.17.0/24. L2 dumb switches can not make L3 decisions. The traffic gets passed to the green interface because it has to make the decision on where the L3 PiHole is, then the same in reverse. As you can see from packet captures, Traffic fully transverses from wifi client all the way through the network passing through green in route to 172… once there, back through the network it goes arrives at IPFire and then attempts the next connection but never arrives at the WiFi router over cat 8. This means that either I am missing a routing table rule that is vital or something else is stopping it at IPFire.

I checked IPS logs, Firewall Logs, and do not see anything being dropped, although I feel its there on IPFire. Has to be… if it arrives at IPFire on the reverse trip looking for the final ACK from 10.10.90.0/24 and never arrives at the other end of the 8 foot cat 8 cable. That should bring you to the same conclusion.

I will grab my routing table shortly.

Eric

16

Why should the traffic go through IPFire?
IPFire, PiHole, AP are all devices on green network, connected through the switch.

1 Like
17

Well I certainly found 1 problem… I already had an entry in IPFire pointing 10.10.90.0/24 to the assigned WAN port on the internal WiFi Router of 172.16.17.32, but dang weird its not showing up within the Kernel Routing Table itself on IPFire.

image
image1259Ă—698 43 KB

Apparently, I am not the only person who’s ran into this missing entry…
and based on the posting date below by

jhylkema » March 25th, 2018, 8:32 am – Looks like its still a problem and this person never did get a response either… LOL

https://forum.ipfire.org/viewtopic.php?t=20511

[root@ipfire suricata]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 204 0 0 red0
172.16.17.0 0.0.0.0 255.255.255.0 U 0 0 0 green0
192.168.1.0 0.0.0.0 255.255.255.0 U 204 0 0 red0

[root@ipfire suricata]# ping 172.16.17.165
PING 172.16.17.165 (172.16.17.165) 56(84) bytes of data.
64 bytes from 172.16.17.165: icmp_seq=1 ttl=64 time=0.295 ms
64 bytes from 172.16.17.165: icmp_seq=2 ttl=64 time=0.181 ms
64 bytes from 172.16.17.165: icmp_seq=3 ttl=64 time=0.172 ms
64 bytes from 172.16.17.165: icmp_seq=4 ttl=64 time=0.249 ms
^C
— 172.16.17.165 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3039ms
rtt min/avg/max/mdev = 0.172/0.224/0.295/0.051 ms
[root@ipfire suricata]# ping 10.10.90.58
PING 10.10.90.58 (10.10.90.58) 56(84) bytes of data.
^C
— 10.10.90.58 ping statistics —
2 packets transmitted, 0 received, 100% packet loss, time 1010ms

[root@ipfire suricata]# ping 10.10.90.1
PING 10.10.90.1 (10.10.90.1) 56(84) bytes of data.
64 bytes from 10.10.90.1: icmp_seq=1 ttl=64 time=0.557 ms
64 bytes from 10.10.90.1: icmp_seq=2 ttl=64 time=0.658 ms
64 bytes from 10.10.90.1: icmp_seq=3 ttl=64 time=0.630 ms
^C
— 10.10.90.1 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2028ms
rtt min/avg/max/mdev = 0.557/0.615/0.658/0.042 ms
[root@ipfire suricata]# ssh pi@172.16.17.165
Host key fingerprint is SHA256 blanked out
±–[ECDSA 256]—+
|.oo…+O=+E |
|o o+oo=+.o |
| .o+o=.+o |
|++oo.o=o o |
|=oo…o+ S |
|+ +… . . |
|.oo o |
|o. o . |
|. . |
±—[SHA256]-----+
pi@172.16.17.165’s password:
Linux pihole-dns-server 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Jul 10 01:59:49 2020 from 172.16.17.1
pi@pihole-dns-server:~ $ exit
logout
Connection to 172.16.17.165 closed.
[root@ipfire suricata]# ssh admin@10.10.90.1
Host key fingerprint is SHA256: Blanked Out
±–[ECDSA 521]—+
| .o B+o |
| .o @.*. |
| . .O o. |
| ooo+. . |
| .ooo=o S |
|.o+ =.oo |
|o+ o.++. |
|.o .+o. |
|E o+. |
±—[SHA256]-----+
admin@10.10.90.1’s password:
admin@gtax11000:/tmp/home/root# exit
Connection to 10.10.90.1 closed.
[root@ipfire suricata]#

18

Note, on IPFire, I can SSH to both PiHole 172.16.17.165 and the WiFi Router at 10.10.90.1 via 172.16.17.32

19

Bernhard,

Here is my routers ARP table on Wifi It is inclusive on 10.10.90.0/24 network

image
image1025Ă—466 23.3 KB

Here is my IPFire ARP table Green on LAN physically connected to Switch then to 10.10.90.0/24 via WAN 172.16.17.32.

image
image1275Ă—888 61.2 KB

There is no entries at all for the 10.10.90.0/24 network

Maybe this is why I am having a problem. Who knows. Maybe the dumb Non-Configurable Gigabit switch is reallly really dumb. LOL… I guess its possible?

Also, this could be the information you are looking for?

This is a pretty common misconception or more specifically, a terminology problem. In a layer two switch, there is not an ARP table, only a forwarding table. The switch records each src MAC address it sees inbound in the forwarding table, and attributes it to the port so frames with a dst MAC will only get sent to the port known for that MAC. Many people call this an “arp table” or “arp cache” even though it is neither.

20

To make it clear once more.
I do not have your problems. And yes, I know how network traffic flows and is managed.
Your configuration uses three networks:

  • WAN : attached to IPFire’s red0
  • LAN: attached to IPFire’s green0
  • Wireless: attached to AP’s WLAN interface

The routing between WAN and LAN is done by IPFire, further there is a firewall active.
Routing between LAN and wireless is done by your AP, with or without a firewall ( don’t know ).

Physically ( on ethernet layer ) the devices in green are connected by a switch.

Traffic in LAN should be directly between devices, they all belong to the same network .172.16.17.0/24

1 Like