Hello,
I have been trying to solve the following issue for the last few days without success, here is a summary of my setup (diagram also attached bellow):
Because I cannot setup my ISP's router in Bridge mode, I am currently using the OpenWRT router behind my ISP's router.
I am using three interfaces in OpenWRT, with each one being assigned its own VLAN and Firewall zone:
WAN: which contains the port connected to the ISP's router. There I am using the ISP's router's DHCP and assigning a static IP to my OpenWRT.
LAN: which contains a DNS server (Pi-Hole) along with some other devices.
TV: which contains smart TVs I want to isolate from the rest of the network.
I have set both LAN and TV to use the Pi-hole DNS server (this allows to perform DNS filtering for some Ads/telemetry, etc).
I have some devices connected directly into my ISP's router, which I have also manually configured to use the Pi-hole.
My issue is with the Firewall configuration (Attached bellow).
The configuration for Zone WAN has the "masquerade" box checked in, I believe this was the default in the WAN zone. Initially I hadn't bothered to change it. However, as the "WAN" interface from the point of view of my OpenWRT is still within my private network, I thought that this setting was not really required so I disabled it. To my surprise, in doing so, I noticed requests to the Pi-Hole DNS server were timing out, and were not being responded to.
Here are a few additional interesting facts:
Using wireshark on a machine from my LAN zone, I could see that DNS requests were replied to using the Pi-Hole's real IP address (and not OpenWRT's) which again just confuses me as to what the masquerading option really is doing.
Looking into the logs of my Pi-Hole, I can see the requests do reach it, so I assume it is just the responses that are not making it back to the clients.
Initially I thought only requests from the WAN zone were having this issue (using Laptop 1), but performing DNS requests from within the LAN zone (Laptop 2) showed the same issue, which I really do not get.
if you deactivate the "masquerade" on the wan you only have two possibilities: either you transform your router into a dump-AP (but you will not have any other additional networks just one large network with ip addresses 192.168.0.0/24) or you create a path on your ISP router that routes the packets of the 192.168.1.0/24 network towards your router with the IP address 192.168.0.2
Yes, I have that configured, apologies it slipped my mind to also include it in OP.
I couldn't set it on the ISP router, but on the host present on the "WAN" zone which I want to be able to reach the Pi-Hole, I have configured extra routes for 192.168.1.0/24 ("LAN" zone) and 192.168.2.0/24 ("TV" zone) to use 192.168.0.2 (OpenWRT) as gateway.
This works, since my requests do reach Pi-Hole, it is the responses not reaching the clients back that is confusing me
Isn't masquerading supposed to work in the other direction? i.e. all packets emanating out of the OpenWRT into the "WAN" area should have the router's own IP (192.168.0.2) as source? Looking through the logs of the Pi-Hole I can see the real IP Addresses of the clients are not being masked by that of the "OpenWRT"...
If your OpenWrt router does not masquerade the LAN and TV networks, your ISP is going to receive packets on it's LAN interface, with a source IP address outside it's LAN range, and will reject them.
your ISP is going to receive packets on it's LAN interface
This might be me misunderstanding things, but since my OpenWRT router and my ISP's router's are on the same LAN, no routing is needed, my OpenWRT router would just address the DNS responses using the MAC addresses of whatever device sent the request, right?
Your ISP router seems to be on 192.168.0.0/24 while your OpenWRT router seems to be on 192.168.1.0/24
That is not the same subnet
Edit: if your TV's and appliances are connected by ethernet cable to your OpenWRT router you can bridge the WAN and that specific LAN port so that your TV's etc are using the ISP's router
The 192.168.1.0/24 range is set on OpenWRT's LAN's interface, this interface also has its default gateway to be 192.168.0.1 (which belongs the WAN interface).
Looking at OpenWRT's WAN interface, the range there is set to match the ISP's LAN (192.168.0.0/24), as you can see on the diagram, on the WAN interface OpenWRT has IP address 192.168.0.2.
Looking at firewall rules, forwarding from LAN to WAN is allowed.
With my OpenWRT being on both LAN's and forwarding from LAN to WAN being allowed, why are my packets still not making it out of the LAN unless masquerading is on?
so that your TV's etc are using the ISP's router
But my goal is to have those device in a separate VLAN and firewall zone, I don't think I can get that working if I go the bridge way right?
In that case everything is on the same subnet
Yeah that's the issue...that's the opposite of what I want
Again, I really appreciate your help
One step back: why do you want to disable MASQUERADE on the WAN of the OpenWRT router?
It is not impossible to do it without MASQUERADING if you set up static routing on the ISP router but why?
If your goals is to reach your OpenWRT routers LAN e.g. your pihole from the ISP LAN then, besides the static routes, you also have to open up the firewall of the OpenWRT router to allow traffic from 192.168.0.0/24
But it does not matter if you MASQUERADE or not on the WAN interface
The masquerading was setup by default on the WAN interface. Since my OpenWRT is anyway behind my ISP's router, I figured I don't really need masquerading, and wanted to disable it, but then DNS requests stopped getting replied to.
Yeah, that too is what I don't understand
Like I said requests do reach the DNS server, its is responses that do not make it back out of the LAN....
Yep, those are already allowed, since I can reach LAN devices from the WAN interface, I believe the issue is not in the firewall rules.
I assure you, keeping everything the same, disabling and enabling masquerading is the only variable in my testing
It isn't clear if you have, but you must install a route in the ISP router 192.168.1.0/24 via 192.168.0.2. Then when the ISP router gets a packet for a 192.168.1 IP it knows to send it to the OpenWrt router.
In order for a 192.168.0 device to originate a connection to a 192.168.1 device (e.g. the Pi-Hole), it is necessary to add a wan->lan forwarding through the OpenWrt firewall. The default firewall only has lan->wan forwarding. Incoming connections from the wan side will be blocked in that case.
If you're using the DNS server in OpenWrt to redirect to the Pi-Hole, then it's also necessary to open port 53 in the OpenWrt firewall so that OpenWrt can serve DNS to the 192.168.0 side. Opening ports 22, 80, and/or 443 would allow the laptop on the 192.168.0 network to log into OpenWrt via ssh or http respectively.
MAC addresses are only relevant on the same layer 2 network segment (for example, two 192.168.1 devices linking to each other). When a router is reached, the MAC address is discarded and routing proceeds based on IP address.
Hello @mk24,
Thank you a lot for the reply, here are my answers to your remarks:
Adding routing on the ISP router: that is not an option for me on the ISP router, currently I am doing that on the client devices themselves, and that seems to be working as I can reach devices in the LAN from the WAN.
WAN-to-LAN forwarding: you are correct, the default zone policy does not allow for this, but I added specific Firewall rules to allow SSH and DNS access, as well as access to my PiHole's web interface. I am attaching a screenshot of the Firewall Rules I added.
Examining the issue further, I noticed that when disabling masquerading, what happens is that my Pi-Hole's request to its upstream DNS server fail. In fact, when masquerading is turned off on the WAN interface, no requests seem to make it out of the LAN network, even-though the default policy is to allow forwarding from LAN to WAN
This will not work when an unmasqueraded 192.168.1 device such as the Pi-Hole accesses the Internet. The ISP router will masquerade the 192.168.1 IP to the house's public IP. The problem occurs after the response from the external server has been de-masqueraded back to the Pi-Hole's 192.168.1 IP. At this point the ISP router does not know what to do with the packet, since it does not have a route to 192.168.1.0. There needs to be a way to add routes to the ISP router's routing table in order for a non-NAT secondary router to be feasible.
Thank you @mk24 ! This finally makes sense!
I had assumed that since my OpenWRT was still behind another router and had no way of directly reaching the Internet, masquerading was not necessary. But I now see how without a way to configure the route to 192.168.1 on the ISP router, there is no way of getting responses back to anything behind OpenWRT without masquerading.
Again, thank you! Not understanding this was driving me crazy
