Firewall VLAN Setup Help

gravity · October 19, 2020, 10:16pm

Would appreciate help with setting up VLAN's & Firewall, been at this for over a month now and the way things are done confuse me greatly. I have read the docs over and over, and searched videos and asked people for help. I can't get things setup how I want. Granted I am slightly new to dealing with all this. I am not on my network at this moment, so I can't grab the exact files from the router, however I can attempt to give a rundown of my setup and my issues. If you want to see a certain file, ask and I can grab it when I get on my network.

I am not entirely sure what I have setup right, and what I don't. I'd like to avoid starting fresh, and just try to fix what I already have because I think it's just a few firewall settings that need to be changed around. I just don't know if my current setup, matches my goals, and also the few issues I am having.

Thanks.

Hardware Setup
I have OpenWRT router and a laptop running Pihole for DNS, and NGINX for my media server (Ports 80 and 443 are open for this).
Router at 192.168.5.4, and Pihole at 192.168.5.5.

I have two unmanaged switches going into the house. One is only family stuff and the other is mine. Both go directly into the router.

I have a printer (192.168.40.10) on IOT, other devices may be added to it in the future.

OpenWRT Interfaces
I have 4 interfaces made on Openwrt-LAN, GUEST, LAN2, and IOT.

Interfaces
LAN, Static Address 192.168.5.4/24
LAN2, Static Address 192.168.10.1/24
Guest, Static Address 192.168.30.1/24
IOT 192.168.40.1/24
(ignoring wan and wan6 interfaces)

These are all set to use 192.168.5.5 (pihole) as the DNS, except guest which uses two custom external DNS servers.

Traffic Rules

Allow-DHCP-Renew
Incoming ipv4 UDP,
from wan
to this device port 68

Guest DNS
Incoming ipv4 and ipv6
from guest
to this device port 53
(To allow DNS access for guest vlan)

Guest DHCP
incoming ipv4 and ipv6 prot UDP
from guest
to this device port 67-68
(To allow DHCP access for guest vlan)

LAN2 DNS
incoming ipv4 and ipv6
from lan2
to this device, IP 192.168.5.5
(To allow access to Pihole for DNS access on LAN2)

LAN2 DHCP
incoming ipv4 and ipv6, prot UDP
from lan2
to this device, port 67-68
(To allow DHCP access on LAN2)

LAN2 to LAN
Forwarded ipv4 and ipv6
from lan2
To lan, IP 192.168.5.5, 192.168.5.4, 192.168.5.17, 192.168.5.67
(My attempt to access my media server from LAN2, however this seems to not be working entirely as I expect? Not sure.)

IOT DHCP
incoming IPv4 and ipv6
from iot
to this device, port 67-68
(To allow DHCP access on IOT)

Printer to LAN
Forwarded IPv4 and IPv6
From IOT, 192.168.40.10
to LAN
Accept forward
(An attempt to access the printer on IOT, on LAN. I just added the printer today, however this does not seem to be working at this current moment.)

Printer to LAN2
Forwarded IPv4 and IPv6
From IOT, 192.168.40.10
to LAN2
Accept forward
(An attempt to access the printer on IOT, on LAN2. I just added the printer today, however this does not seem to be working at this current moment.)

Firewall
Basic Rules

Enable SYN-flood protection on
Drop invalid packets on
Default Rules,
Input: Drop
Output: Drop
Forward: Drop

Software and Hardware flow offloading enabled.

Firewall Zones
lan >> wan
input accept
output accept
forward reject

wan >> drop
input drop
output accept
forward drop

guest >> wan
input drop
output accept
forward drop

lan2 >> wan
input accept
output accept
forward reject

iot >> wan
input drop
output drop
forward drop

Custom Rules
iptables -t nat -A PREROUTING -i br-lan ! -s 192.168.5.5 -p udp --dport 53 -j REDIRECT
iptables -t nat -A PREROUTING -i br-lan ! -s 192.168.5.5 -p tcp --dport 53 -j REDIRECT
iptables -t nat -A PREROUTING -i eth0.2 -p udp --dport 53 -j REDIRECT
iptables -t nat -A PREROUTING -i eth0.2 -p tcp --dport 53 -j REDIRECT

meant to force lan to use the pihole, will probably also have to duplicate this in for lan2, guest, and IOT after it's all setup and the switching I guess.

Wireless Access Points
5ghz
ssid: primary internet
network lan

5ghz
ssid: my internet
network lan2

2.4ghz
ssid: family internet
network: lan

2.4ghz
ssid: my internet
network: lan2

guest 2.4
ssid: guest network
network: guest

iot 2.4
ssid: iot network
network: IOT

How I Want My Setup and Issues
So my goals are as follows,

Both LAN and LAN2 should be able to access the router configuration page, however Guest, IOT should not.
I want my family LAN to not be able to interact with my LAN2 in any way except specified.
The specifications are, that I can access the Pi-Hole on LAN for my DNS at LAN2.
Guest should be completely isolated, not even have access to the Pi-Hole for DNS.
I setup custom DNS servers for the guest interface.

It seems like I may have gotten the guest and LAN and LAN2 setup properly for wireless, however I'd appreciate if it could be checked over. I can access websites, and I have my DNS for LAN and LAN2 interfaces set to use 192.168.5.5 (pihole), and I can connect to websites. However I am having issues with my media server when crossing over (the media server is still on LAN, I talk about this below)

I set this up using the traffic rules, however I am not entirely sure if it is setup as I expect it to be?

I have the two unmanaged switches, one for family and one for my stuff, I was hoping to separate these so say SWITCH1 is for LAN, and SWITCH2 is for LAN2 and they can't interact with each other (again except for what is specified, so like the Pi-Hole being able to cross the network for DNS).
This I have not messed with yet, as I am not familiar with tagging and stuff, and was getting confused. I figured it'd be best to wait and setup everything else and ensure it works 100% then mess with this.
I do have a media server (jellyfin/airsonic) (which is also used as a computer), which I'd like to be on LAN2, but it also needs access to LAN for NGINX on the Pihole.
However, I also don't want LAN to lose access to a direct connection to the media server, and be required to travel through the public internet (which the media server can do, however the local link would be nice to keep), but I also don't want to expose that computer to LAN besides for the media server.

With my current setup, if I cross over to my LAN2 network, I get a "Forbidden Rejected request from RFC1918 IP to public server address" error when going to the jellyfin domain, however I have no issues pinging that device local IP across vlan. I can reach it no issues if I hop onto LAN vlan.

I'm unsure exactly how I would properly set this media server up for firewall? It's still on LAN though because LAN users need to access it, and if I move it over, they will not (for the same reason I can't access it on LAN2 while it's on LAN.) Also I haven't figured out switching, and this device is wired.

I have the printer on the IOT network, I do not want anything on this network to have access to public internet, I've not dealt with a printer before, however I assume this is possible as it receives the data from the computers on the lan, so I see no reason why it needs to connect to the public internet. So I would like it to be completely isolated to LAN and LAN2 for usage, and have ZERO internet connectivity. Of course anything else that goes on this interface will not have internet too I am aware.

Would greatly appreciate help again, I have read through the docs, however I am still slightly new to all of this and it has been giving me massive headaches, I've been at this one and off for months trying to get everything setup properly. Some things are working, some are kind of working, and some just don't seem to be working. Would appreciate help.

trendy · October 20, 2020, 10:47am

INPUT for LAN and LAN2 zones ACCEPT.

LAN and LAN2 in different zones, no forwarding between the zones, open flows with rules.

Guest zone only allowed to forward to wan. Allow port 67/udp on router for dhcp.

Unmanaged switches cannot handle tagged frames properly. The only thing you can do is multiply the available ports for lan and lan2.

I don't follow.

This is some internal server error, not directly connected to OpenWrt.

If the IOT is not supposed to have internet access, then don't enable the IOT to WAN forwarding. Enable LAN/LAN2 to IOT.

gravity · October 20, 2020, 4:21pm

First I think part of my major confusion stems from misunderstanding how INPUT, OUTPUT, and FORWARD, works in coherence with the zones.

My understanding is, INPUT govern traffic coming into the system (I assume the router), OUTPUT governs traffic leaving the system, and FORWARDING is between the interfaces? (LAN to WAN?) But I don't entirely understand how I can reject forwarding, and allow input/output and still have internet, because this is how it currently is, and I can get internet no issues.

I think this is where I am getting tripped up and why I am still so confused. I'm just not understanding how these rules actually function within the network.

Both LAN and LAN2 should be able to access the router configuration page, however Guest, IOT should not.

INPUT for LAN and LAN2 zones ACCEPT.

lan >> wan
input accept
output accept
forward reject

lan2 >> wan
input accept
output accept
forward reject

So essentially my current setup above for lan and lan2 are correct for this part.
And then on the guest and IOT vlans, input should be set to reject/drop?

I want my family LAN to not be able to interact with my LAN2 in any way except specified.
The specifications are, that I can access the Pi-Hole on LAN for my DNS at LAN2.

LAN and LAN2 in different zones, no forwarding between the zones, open flows with rules.

Can you elaborate on this? If you peek at my current firewall zones, it is like such:

lan >> wan
input accept
output accept
forward reject

lan2 >> wan
input accept
output accept
forward reject

Is this what I want?
Also what do you mean by open flows with rules?

Guest should be completely isolated, not even have access to the Pi-Hole for DNS.
I setup custom DNS servers for the guest interface.

Guest zone only allowed to forward to wan. Allow port 67/udp on router for dhcp.

currently I have it setup to output accept, and drop forwards. Would blocking output not disable internet access?

guest >> wan
input drop
output accept
forward drop

I have the two unmanaged switches,

Unmanaged switches cannot handle tagged frames properly. The only thing you can do is multiply the available ports for lan and lan2.

Again, I'm not familiar with switching, but should I not be able to simply isolate the two switches? (The Archer C7's built in switch acts as the managed switch, for the unmanaged switches) Because all of my familys devices are on one unmanaged switch, and all of my devices are on the other, I should be able to simply isolate one switch from the other switch, no? I don't see how the actual devices on the switches play a role here, except in the case where the devices were mixed between the switches, however they're not. My family has their own switch, and I have my own. So I should be able to simply put a block between the two?

Or are you suggesting there will be issues if I need to cross over for certain devices? I only need crossover on two devices (Pihole/NGINX and Media Server), so maybe I should plug these two devices directly into the router switch instead of the unmanaged switches?

However, I also don't want LAN to lose access to a direct connection to the media server, and be required to travel through the public internet (which the media server can do, however the local link would be nice to keep), but I also don't want to expose that computer to LAN besides for the media server.

I don't follow.

Essentially the desktop computer ("media server") can be reached from outside the network (for remote access to jellyfin), (travels to the pihole machine for nginx reverse proxy). I would ideally like to have a local link when on both LAN and LAN2, however I'd like to ideally limit LAN to only access that media machine for jellyfin (meaning it's completely isolated besides jellyfin access essentially). I'm unsure how exactly this should be done, because I assume it has to pass through nginx on the other machine as well, so do I forward the ports jellyfin uses on that machine? Or do I just forward 80 and 443 to LAN? I assume the latter?

I assume if I block LAN from being able to access the server with the firewall, it would be reaching it publicly, not over the local link? Which is what I wanted to avoid if possible.

Sorry if that was confusing.

If the IOT is not supposed to have internet access, then don't enable the IOT to WAN forwarding. Enable LAN/LAN2 to IOT.

So you're suggesting removing the IOT WAN zone in favor of a IOT to LAN and LAN2 zone? Ok.

Haven't messed with anything yet, just making this reply for now.
Also thank you so much for your time here.

trendy · October 20, 2020, 4:34pm

INPUT rules for a zone describe what happens to traffic trying to reach the router itself through an interface in that zone.

OUTPUT rules for a zone describe what happens to traffic originating from the router itself going through an interface in that zone.

FORWARD rules for a zone describe what happens to traffic passing between different interfaces belonging in the same zone.

The forwarding sections control the traffic flow between zones

That's fine. Create individual traffic rules to allow traffic from LAN to LAN2 and vice versa.

No, but still it is not necessary to drop the output.

Yes, that's what I meant. Create a new vlan on the internal switch of the OpenWrt to assign a port on that vlan and use separate lan and lan2.

I am not sure, but no matter what, you can block its access regardless if it is in LAN, LAN2, or IOT.

It depends what do you want to achieve. You can allow iot->wan and then block some hosts which should not access internet. Or don't allow iot->wan and allow with a rule only a handful of hosts.

gravity · October 21, 2020, 5:19pm

OUTPUT rules for a zone describe what happens to traffic originating from the router itself going through an interface in that zone.
FORWARD rules for a zone describe what happens to traffic passing between different interfaces belonging in the same zone.

Would blocking output not disable internet access?

No, but still it is not necessary to drop the output.

This is what I don't understand about the configuration.

If the two interfaces in the zone is LAN to WAN, and OUTPUT controls what happens to traffic originating from the router, what exactly would this block (if output was set to drop/reject) in this example?

So I'm confused the use on OUTPUT, I guess. In correlation with why FORWARD doesn't work as I expect it to?

It seems like if I were to drop/reject FORWARD requests on LAN to WAN, it should not allow internet access, however I am rejecting FORWARDS on both LAN to WAN, and LAN2 to WAN zones, and can achieve internet fine. Which is why I am confused, because if FORWARD supposedly governs the traffic passing between the interfaces, and FORWARD is rejected/dropped, all traffic requests coming from LAN/LAN2 going to WAN should not work, meaning they would not be able to make outgoing requests to websites.
So I fail to understand why even though I am blocking forwards, I do not have issues with the internet?

It depends what do you want to achieve. You can allow iot->wan and then block some hosts which should not access internet. Or don't allow iot->wan and allow with a rule only a handful of hosts.

I assume you mean like IP/MAC Address blacklisting? What would be the best way to achieve this (If I allow IOT to WAN, and want to not allow two different devices)? I know there are blacklisting rules possible for what devices can access a wireless access point, however not on a connection level beyond actually connecting to the access point.

krazeh · October 21, 2020, 5:45pm

FORWARD relates to interfaces within the zone. So, for example, if you had two interfaces within the LAN zone you can allow, drop, or reject forwarding between them. It has no bearing on forwarding to other zones.

gravity · October 21, 2020, 10:54pm

FORWARD relates to interfaces within the zone. So, for example, if you had two interfaces within the LAN zone

I am still slightly confused, because trendy suggests

LAN and LAN2 in different zones, no forwarding between the zones, open flows with rules.

But what would dictate forwarding between the zones.

It would make more sense to me, that in a zone "LAN to WAN", forward simply controls everything going from interface LAN to interface WAN. But as you state, it is if there are two interfaces in that LAN.
But then how do you control the forwarding between the zones?

And I'm still confused on the use case of OUTPUT.

OUTPUT rules for a zone describe what happens to traffic originating from the router itself going through an interface in that zone.

Seeing everything has to go to the router, and then come out (to reach LAN or WAN), so for example if I ping computer2 from computer1 (LAN or WAN, doesn't matter), it goes from computer to router, then has to be routed to another device, but if OUTPUT is set to drop, it can never go out to the specified interface.
It sounds like a glorified block which doesn't seem right, So I think I am misunderstanding.

I work best with real world examples, that could help.
Thank you so much for your help.

trendy · October 22, 2020, 7:34am

OUTPUT is for the traffic which originates from the router. If for example you ping from the router or try to download and update for the router. If traffic came from one interface and goes out another, then it is FORWARD.

Let's assume zone LAN has 2 interfaces, lan1 and lan2 with networks 192.168.1.X and 192.168.2.X.
If FORWARD in LAN zone is ACCEPT then all traffic from 192.168.1.X to 192.168.2.X and vice versa is ALLOWED. Otherwise with DROP/REJECT it is blocked.

Another example: lan is 192.168.1.X and belongs to lan zone. iot is 192.168.2.X and belongs to iot zone. By default traffic from one zone to another is denied. You'll need to create a forwarding to allow flows from 192.168.1.X to 192.168.2.X. Forwardings are unidirectional, so if you want to allow from iot to lan a second forwarding is needed.

If you don't add forwardings, which would allow all traffic, you can create rules for specific flows. For example you can create a rule for source zone lan, source IP 192.168.1.10 to access destination zone iot, destination IP 192.168.2.23 tcp 443 port to be ACCEPT. Then only this flow is accepted.

gravity · December 3, 2020, 3:41pm

Ok, sorry late response.
So, I've been messing with it, and I think I got the idea down I'm just running into two (final?) issues.

So let me make clear my current configuration,

Under switches, keep in mind it's two unmanaged switches that go into the router's managed switch. All my stuff is on one unmanaged switch, and all my families stuff is on the other unmanaged switch. The pihole is on my unmanaged switch, I set tagging on cpu for all of them, the pihole needs to be access on both LAN and LAN2.

Under interfaces > LAN2 > Physical settings, I have it set to bridge, and for interfaces I have the eth3.0 for my unmanaged switch, and my wireless.
Then I have eth0.1 for LAN.

I have two different IP ranges set for each interface under general, one is 192.168.1.1 (LAN) and the other being 192.168.2.1 (LAN2).
intflan

Now coming to the zones.

My first concern being:

I have set custom rules to force everything to the Pihole. 192.168.2.3 is the Pihole. 192.168.1.1 is the OpenWRT router. The mac address (00:00:00:00:00:00) is the pihole's ipv4 mac.
I got this from a post you (@trendy) made in another thread, not sure if I did this right though. I can't entirely say I understand exactly everything it's doing. I'm not familiar with masquerading or nat much. Also I wasn't sure if I was supposed to replace the "prerouting_lan_rule", "guest_rule", and "iot_rule".

And I'm secondly unsure if these rules are applying across the vlans.

Keep in mind, my IOT vlan, my LAN, and LAN2 vlans should all use the Pihole. The guest network however should use my specified DNS addresses (I set in interface > guest > dns servers).

#
# DNSHIJACKv4
# Log and hijack to Pihole
iptables -t nat -N dnshijack
iptables -t nat -I dnshijack -j LOG --log-prefix "dnshijack4 "
iptables -t nat -A dnshijack -j DNAT --to-destination 192.168.2.3
# allow Pihole to query internet
iptables -t nat -A prerouting_lan_rule -m mac --mac-source 00:00:00:00:00:00 -p udp --dport 53 -j ACCEPT
iptables -t nat -A prerouting_lan_rule -m mac --mac-source 00:00:00:00:00:00 -p tcp --dport 53 -j ACCEPT
# allow queries to OpenWrt
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -d 192.168.1.1 -j ACCEPT
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d 192.168.1.1 -j ACCEPT
# anything else is hijacked
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -j dnshijack
# other zones
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d 192.168.1.1 -j ACCEPT
# anything else is hijacked
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -j dnshijack
# other zones
iptables -t nat -A prerouting_guest_rule -p tcp --dport 53 -d 192.168.2.3 -j ACCEPT
iptables -t nat -A prerouting_guest_rule -p udp --dport 53 -d 192.168.2.3 -j ACCEPT
iptables -t nat -A prerouting_guest_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_guest_rule -p tcp --dport 53 -j dnshijack
iptables -t nat -A prerouting_iot_rule -p tcp --dport 53 -d 192.168.2.3 -j ACCEPT
iptables -t nat -A prerouting_iot_rule -p udp --dport 53 -d 192.168.2.3 -j ACCEPT
iptables -t nat -A prerouting_iot_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_iot_rule -p tcp --dport 53 -j dnshijack
# fix "reply from unexpected source"
iptables -t nat -A postrouting_lan_rule -d 192.168.2.3 -p tcp -m tcp --dport 53 -m comment --comment "!fw3: DNS Pi-hole MASQUERADE" -j MASQUERADE
iptables -t nat -A postrouting_lan_rule -d 192.168.2.3 -p udp -m udp --dport 53 -m comment --comment "!fw3: DNS Pi-hole MASQUERADE" -j MASQUERADE

So besides that, currently where I stand, I can get internet access on both VLANs, and DNS queries work fine on both LAN and LAN2 (I didn't test IOT). However I have two concerns, one I'm not sure if it's isolating properly, and two I can't reach my Jellyfin server across LAN.

Starting with the Jellyfin server issue, originally it was on LAN with my other devices, and when I went on LAN2 I was getting that RFC1918, I never got that figured out still working on that however it's irrelevant at this moment because I moved it to LAN2, and now I can't even access it. Before I could still go on the opposite lan type in "192.168.1.10:8096" for jellyfin, and access it locally, I just got that RFC1918 when trying to use the actual domain name.
Now though, I cannot even access the JF server when I cross from LAN2 (which it now sits on) to LAN. I did have a traffic rule previously setup, but I made a new one reversed, but it doesn't seem to be working. See my traffic rules in the picture below.

Secondly the other issue is related to traffic rules as well.
Currently I cannot ping devices between each vlan, but when I hop on the vlan, I can. This tells me everything is isolated (or at least seems so). However if I remove my newly added DNS rule to allow src LAN to access Pihole for DNS on port 53 at dst LAN2, I still can access websites no issues on LAN. Which is my issue, if it's truly isolated, I should not have DNS access on lan when that rule is disabled, right? SO idk why I still do. Unless it's because the custom dns hijacking rules above are forcing it.

I wasn't sure if it should've been LAN2 to LAN instead of LAN to LAN2, LAN to LAN2 seemed right because LAN needs to be able to make the request to LAN2. Unless I need two separate rules, that say LAN to LAN2 and then LAN2 to LAN, but I assume LAN to LAN2 is sufficient because I assume it acts as an established connection and allows a return.

I tried plugging in ethernet to my laptop, and I can't get any ping responses to public addresses ("8.8.8.8") if I plug into the LAN interface while having a static ip on the laptop set to the LAN2's IP range (2.1/24) (and set the default gateway to LAN2's interface), if I swap it to (1.1/24) range to match LAN, it works. And if I go on my other ethernet switch for LAN2 , set it to LAN's IP range (and LAN gateway ip), it doesn't work, but if I set it to LAN2's interface, it works. So that seems good, and working as it should.

So isolation seems to be there, so I'm confused on why I can get DNS on LAN when I disable the traffic rule allowing it. And why I can't access my Jellyfin server on LAN2, when on LAN when I made a traffic rule allowing it.

Here are the two rules though, the Jellyfin (2.10) and Pihole ones.

So besides those two issues, ensuring the VLANs are actually isolated, and then ensuring that the custom rules for dns hijacking are correct (which I don't think they are currently), as well as being able to access my Jellyfin server at least locally (I can figure out the RFC1918 issue later on, I just want to get local access across VLANs working first.)

Thank you so much for your time, sorry if this is confusing. Feel free to ask anything.

gravity · December 3, 2020, 5:19pm

Just removed the port 8096 specification and set to all ports, on the Jellyfin rule, and I can access it now. So maybe I needed to forward more than 8096 I guess.

But ok, so yeah got that working. Still getting the RFC1918, not sure why. I wonder if I need to allow LAN to reach port 80 and 443 of the Pihole which is also running NGINX? The firewall on the Pihole is not the issue, already tried disabling it. Didn't see anything else to try in Jellyfin itself, so I think it's a port/openwrt issue.

Still don't understand the DNS isolation however, and I need confirmation on those custom hijacking rules. Thanls.

trendy · December 3, 2020, 10:47pm

I would start by allowing all traffic from lan to the lan2 IP of Jellyfin.
Pihole will work with just port 53 for DNS resolving, but if you want to manage it you'll need to allow 80 or 443 as well.
If you want to harden the rules, you'll have to find out first which ports are needed by Jellyfin and open them accordingly.

gravity · December 6, 2020, 9:41pm

Yeah, I got Jellyfin working.

So where I stand is, I was using the custom rules, and woke up the next day and my DNS was broken, removed the rules and it has been working since.
Those are the rules you provided in another thread, discussing forcing all traffic through Pihole. Not sure if I did them wrong, or if it's because I'm doing stuff across the VLANs?

#
# DNSHIJACKv4
# Log and hijack to Pihole
iptables -t nat -N dnshijack
iptables -t nat -I dnshijack -j LOG --log-prefix "dnshijack4 "
iptables -t nat -A dnshijack -j DNAT --to-destination 192.168.2.3
# allow Pihole to query internet
iptables -t nat -A prerouting_lan_rule -m mac --mac-source 00:00:00:00:00:00 -p udp --dport 53 -j ACCEPT
iptables -t nat -A prerouting_lan_rule -m mac --mac-source 00:00:00:00:00:00 -p tcp --dport 53 -j ACCEPT
# allow queries to OpenWrt
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -d 192.168.1.1 -j ACCEPT
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d 192.168.1.1 -j ACCEPT
# anything else is hijacked
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -j dnshijack
# other zones
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d 192.168.1.1 -j ACCEPT
# anything else is hijacked
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -j dnshijack
# other zones
iptables -t nat -A prerouting_guest_rule -p tcp --dport 53 -d 192.168.2.3 -j ACCEPT
iptables -t nat -A prerouting_guest_rule -p udp --dport 53 -d 192.168.2.3 -j ACCEPT
iptables -t nat -A prerouting_guest_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_guest_rule -p tcp --dport 53 -j dnshijack
iptables -t nat -A prerouting_iot_rule -p tcp --dport 53 -d 192.168.2.3 -j ACCEPT
iptables -t nat -A prerouting_iot_rule -p udp --dport 53 -d 192.168.2.3 -j ACCEPT
iptables -t nat -A prerouting_iot_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_iot_rule -p tcp --dport 53 -j dnshijack
# fix "reply from unexpected source"
iptables -t nat -A postrouting_lan_rule -d 192.168.2.3 -p tcp -m tcp --dport 53 -m comment --comment "!fw3: DNS Pi-hole MASQUERADE" -j MASQUERADE
iptables -t nat -A postrouting_lan_rule -d 192.168.2.3 -p udp -m udp --dport 53 -m comment --comment "!fw3: DNS Pi-hole MASQUERADE" -j MASQUERADE

If I remember, it looked like it was something relating to the mac address in OpenWRT's log? I could be wrong though. Note the 00:00:00 in the above is just a placeholder, I used my ipv4 mac address from my Pihole machine.

trendy · December 7, 2020, 11:31am

In my case the Pihole is in LAN. You have to adapt it if it belongs to another zone.

gravity:

# other zones
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d 192.168.1.1 -j ACCEPT

# anything else is hijacked
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -j dnshijack

The second instance is redundant.

There seems to be also an IP mismatch. You have Pihole 192.168.2.3 but OpenWrt in lan has 192.168.1.1 ?

gravity · December 7, 2020, 2:38pm

There seems to be also an IP mismatch. You have Pihole 192.168.2.3 but OpenWrt in lan has 192.168.1.1

I'm confused what you're asking,OpenWRT would be on LAN1 @ 1.1, and the Pihole is on LAN2 at 2.3.
168.1.0 is LAN1 range, 168.2.0 is LAN2 range.

ignore the ips, they're 100% right to match the devices. Sorry I was playing around with my ips and ranges and was changing things. I can guarantee the IPs match with the devices they're going too I double checked. Sorry I'm making this very confusing.

The second instance is redundant.

Wdym? One is tcp and the other is udp.

You have to adapt it if it belongs to another zone.

Yeah my issue is what exactly do I have to adapt?
Like if I want to force everything through the Pihole on both LAN and LAN2, do I have to make redundant statements for everything stating dnshijack?

# allow Pihole to query internet
iptables -t nat -A prerouting_lan_rule -m mac --mac-source 00:00:00:00:00:00 -p udp --dport 53 -j ACCEPT
iptables -t nat -A prerouting_lan_rule -m mac --mac-source 00:00:00:00:00:00 -p tcp --dport 53 -j ACCEPT
# allow queries to OpenWrt
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -d openwrtip -j ACCEPT
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d openwrtip -j ACCEPT
# anything else is hijacked
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan2_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan2_rule -p tcp --dport 53 -j dnshijack
# other zones
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d openwrtip -j ACCEPT
# anything else is hijacked
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan2_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan2_rule -p tcp --dport 53 -j dnshijack

# other zones
iptables -t nat -A prerouting_guest_rule -p tcp --dport 53 -d openwrtip -j ACCEPT
iptables -t nat -A prerouting_guest_rule -p udp --dport 53 -d openwrtip -j ACCEPT

If I wanted to allow guest zone to bypass pihole, do I just remove the guest rules in the last part like above? I can't manually specify each mac address that connects obviously. Or do I just place the openwrt address instead of the pihole?

iptables -t nat -A prerouting_guest_rule -p tcp --dport 53 -d openwrtip -j ACCEPT
iptables -t nat -A prerouting_guest_rule -p udp --dport 53 -d 1openwrtip -j ACCEPT

trendy · December 7, 2020, 2:59pm

Make sure the openwrtip you are using matches the IP for the interface of this zone.

All 3 rules were used earlier under the comments # allow queries to OpenWrt and # anything else is hijacked

In your case lan2 is what I use as lan. And for your lan you can use the rules I have for guest or iot.

The default action is ACCEPT, so if there is no jump to dnshijack for guests, then it has no sense to be there.

gravity · December 14, 2020, 4:30pm

Pretty much have everything working at this point, just tweaking some stuff.

For the pihole forced dns redirection, I switched to this ruleset (from here), which seem far less complicated and I can actually understand what I'm doing.

They seem to work, I tried (on both vlans) manually setting a public dns on a device, then ran dns leak and it only resolved through the Pihole's dns. So these rules seems to work.

Any opinions? Just was confused why you'd opt for a far more complicated way when this seems to work?

iptables -t nat -A PREROUTING -i br-lan ! -s piholeip -p udp --dport 53 -j REDIRECT
iptables -t nat -A PREROUTING -i br-lan ! -s piholeip -p tcp --dport 53 -j REDIRECT
iptables -t nat -A PREROUTING -i br-lan2 ! -s piholeip -p udp --dport 53 -j REDIRECT
iptables -t nat -A PREROUTING -i br-lan2 ! -s piholeip -p tcp --dport 53 -j REDIRECT
iptables -t nat -A PREROUTING -i eth0.2 -p udp --dport 53 -j REDIRECT
iptables -t nat -A PREROUTING -i eth0.2 -p tcp --dport 53 -j REDIRECT

I also setup the DNS forwarding in DHCP and DNS to forward hostnames to my Pihole (Conditional forwarding setting in Pihole). Seems lik e it can't deal with multiple VLANs though? As in I can only choose one IP range and gateway on the Pihole (see pics).

(Doesn't Work):

(Works):

Any ideas? Or is this pretty much impossible, unless I change my DHCP to be run on the Pihole?

Thanks a lot.

trendy · December 14, 2020, 5:28pm

These rules redirect everything coming not from pihole to the OpenWrt. Extra cycles for the router cpu to process the dns packet, when it will be handled by the pihole eventually.
Is the pihole in lan or lan2? Apparently the same piholeip cannot ingress to both lan and lan2. Or is there one pihole in lan and one in lan2?
What is the point of the last redirect? Is this the wan or some guest/iot?
Do you log to verify that everything is working?

You can manually edit the dnsmasq files in pihole for that.

gravity · December 14, 2020, 11:27pm

Is the pihole in lan or lan2?
Or is there one pihole in lan and one in lan2?

There is only one pihole, in lan2 now since I setup switching.
So I have a traffic rule setup that allows all devices on lan to reach lan2 @ the pihole's ip over port 53.

Apparently the same piholeip cannot ingress to both lan and lan2.

wdym by ingress? it seems to be working currently on both lan and lan2

What is the point of the last redirect?

The eth0.2 redirect? That is the WAN interface.

If you wanted to look at the whole process of what the user did it's here, that's where I got the ruleset. https://teddit.net/r/pihole/comments/av1qd4/setting_up_pihole_on_openwrt/
What the writer said was:

"What we are doing here is redirecting all port 53 traffic on the LAN to the Pi-Hole's while simultaneously excluding them from the forced redirection rules. For me my LAN is named br-lan. Then, we force all traffic on the WAN to redirect. For me, WAN is set as eth1.2. You can find which eth your WAN or LAN is running on in Network -> Interfaces"

Do you log to verify that everything is working?

If I check the system log on OpenWRT, notable stuff relating to DNS-I see
a couple of this

Mon Dec 14 16:59:22 2020 daemon.warn dnsmasq[3381]: reducing DNS packet size for nameserver PIHOLEIP to 1280
and I see these

Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using local addresses only for domain test
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using local addresses only for domain onion
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using local addresses only for domain localhost
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using local addresses only for domain local
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using local addresses only for domain invalid
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using local addresses only for domain bind
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using nameserver PIHOLEIP#53
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using local addresses only for domain lan
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: reading /tmp/resolv.conf.auto
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using local addresses only for domain test
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using local addresses only for domain onion
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using local addresses only for domain localhost
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using local addresses only for domain local
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using local addresses only for domain invalid
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using local addresses only for domain bind
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using nameserver PIHOLEIP#53
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using local addresses only for domain lan
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using nameserver GUEST_DNS_IP#53 
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using nameserver GUEST_DNS_IP#53 
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using nameserver PIHOLEIP#53
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using nameserver PIHOLEIP#53
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using nameserver PIHOLEIP#53
Mon Dec 14 16:42:38 2020 daemon.info dnsmasq[3381]: using nameserver PIHOLEIP#53

Again, I can resolve DNS on devices on both lan and lan2 no issues, and if I go on those devices, change their DNS servers to say 1.1.1.1, then run a DNS leak, it IS not using 1.1.1.1, it is using the 2 pihole upstream servers as it should be. So the redirection rules themselves are working. And the dns resolution is working on both vlans.

The concerning part is most of the stuff seems to be replying as N/A in pihole and some being grayed out. I don't understand why. Which is why I was even questioning the ruleset I'm using (despite it working). It looks almost like it's duplicating or something. See pic below.

trendy · December 14, 2020, 11:39pm

Then checking for source IP of pihole in lan is pointless.

Why would you open dns on the wan interface? Is your pihole accessible publicly from the internet?

That is not correct. What redirect does is to DNAT to the router itself.

All these logs have nothing to do with the redirect.

You can try for example to do an nslookup from a lan2 host towards 8.8.8.8 . If there is no complain about the reply, you are good.
But you are still utilizing cpu cycles of the router to process all these dns queries and almost all the clients in the pihole appear as your gateway.

gravity · December 15, 2020, 12:13am

Then checking for source IP of pihole in lan is pointless.

The conditional forwarding? I tried setting the pihole to grab from the lan2 gateway ip ("IP address of your DHCP server (router)") but it just turns all the client ips to the lan2 gateway ip in the query log of the pihole.

Is your pihole accessible publicly from the internet?

no

look at the quote I listed from that link, the writer says that "we start by redirecting all port 53 traffic on lan to the pihole, while simultaneously excluding them from the forced transition rules", then he goes on to say "Then, we force all traffic on the WAN to redirect.".

What this seemed like to me was that it was just redirecting any traffic going to the WAN interface, to the pihole first.

You can try for example to do an nslookup from a lan2 host towards 8.8.8.8.

did this from my computer, shows it used the pihole.

nslookup 8.8.8.8
Server:  pihole
Address:  192.168.10.5

Name:    dns.google
Address:  8.8.8.8

So that seems all good?
Just not sure why I'm getting those N/A's, and greyed out replies on the Pihole? It is happening quite a lot it seems.

But you are still utilizing cpu cycles of the router to process all these dns queries and almost all the clients in the pihole appear as your gateway.

Idk I couldn't get your method to work, and I was a confused on your replies to my questions on it.
If that way does work better, it would be nice to have it run more efficiently. I just couldn't exactly get it working. I'll try again tomorrow when my network is quiet I guess.

Let me try understanding it though, is this how it should be for my network?

# allow Pihole to query internet
iptables -t nat -A prerouting_lan_rule -m mac --mac-source PIHOLE_MAC -p udp --dport 53 -j ACCEPT
iptables -t nat -A prerouting_lan_rule -m mac --mac-source PIHOLE_MAC -p tcp --dport 53 -j ACCEPT
# allow queries to OpenWrt
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -d LAN_IP -j ACCEPT
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d LAN_IP -j ACCEPT
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -d LAN2_IP -j ACCEPT
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d LAN2_IP -j ACCEPT
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -d IOT_IP -j ACCEPT
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d IOT_IP -j ACCEPT
# anything else is hijacked
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -j dnshijack
# other zones
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d LAN_IP -j ACCEPT
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d LAN2_IP -j ACCEPT
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d IOT_IP -j ACCEPT
# anything else is hijacked
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -j dnshijack
# fix "reply from unexpected source"
iptables -t nat -A postrouting_lan_rule -d PIHOLE_IP -p tcp -m tcp --dport 53 -m comment --comment "!fw3: DNS Pi-hole MASQUERADE" -j MASQUERADE
iptables -t nat -A postrouting_lan_rule -d PIHOLE_IP -p udp -m udp --dport 53 -m comment --comment "!fw3: DNS Pi-hole MASQUERADE" -j MASQUERADE

My confusion on the above is:

why is there
# anything else is hijacked
then
# other zones
then again
# anything else is hijacked
would it not make sense to just remove the first anything else is hijacked, so it's just the last 2? It checks other zones first, then hijacks everything else?

Should I change the prerouting_lan_rule to prerouting_br-lan_rule, and prerouting_lan2_rule/prerouting_br-lan2_rule for the other VLANs? or does this ruleset not care about the interface naming as long as the ips are correct, it's just for user readability?

It seemed to make sense in the above to remove (which I did above) the "other zones" section, because I had to set the IPs at the top for each VLAN, otherwise those LANs wouldn't be able to reach OpenWRT. Is this correct to do?

Lastly,
# anything else is hijacked
What if I want to allow the guest network and any other VLANs to not be hijacked by the Pihole, and use their own DNS servers (not go through the pihole)? This would hijack them.
Or was this the point of the #other zones section? Is this where I should have just set the guest network?

Idk I'm extremely confused trying to work that out and understand it. I get the rules themselves, I'm just confused on what & where I should be separating for the various VLANs, and the ordering.
That's why I went to go look for another ruleset before.