Outbound Zone in NAT rules using LUCI UI

I’m confused about this one entry in the LUCI interface for NAT rules, called ‘Outbound zone”.
Is this the destination zone for the outbound NAT mapping?
Or is this the source zone for the outbound NAT mapping?
After making an entry and hitting save, the screen seems to imply that it is the destination where it shows the “From” and “To”.
If it is the destination, then why is it at the top of the page along with the source address and source port, and not at the bottom along with the destination address and destination port?
And why has it selectively been called “outbound” zone, rather than labeling it “destination” zone like all the other firewall rules?

It‘s the zone where traffic is leaving the router, e.g. the wan one. I guess you could call it destination zone. But in uci it‘s represented by the src option which usually designates the traffic origin. In the case of nat rules it refers to the source interface/address to use for rewriting which must not necessarily be the same as the origin. To be explicit, I decided to call it outbound zone in the ui - it is the zone which contains the egress interface whose address is used for rewriting (and thus essentially becoming the source from an outside pov) but neither the final destination nor the origin of the flow.

Maybe a better term would be „rewrite zone“ but that sounds odd and ambiguous

3 Likes

Thank you so much for helping me out.
I’m a NAT noobie, so I may be asking some dumb questions here.
Let me see if I got this right.
My application for NAT Masquerading is this;

(VLANS)
I have a pihole DNS Server on my lan zone, which is subnet 192.168.3.x.
I have IoT devices on my IoT zone, subnet 192.168.2.x.
I have re-directed (port forwarded) DNS requests from the IoT to the Pihole to take care of hard coded DNS addresses.
I use NAT masquerading to send back to the device on the IoT what was the intended DNS address.
So here’s the flow

192.168.2.x -> 192.168.3.x ->192.168.2.x

If I understand the explanation, the outbound zone in this case would be the Lan. The lan is the source of the Masquerade. Is that correct? (I hope I got this right).

I'm not sure why you are trying to use masquerading for the scenario you've described.

If you already have firewall rules to allow DNS traffic to flow from the iot zone to the DNS server in the LAN zone then the firewall should already allow the responses to pass back.

What exactly are you trying to achieve (or do you think you need to achieve) through the use of masquerading?

It makes the process invisible to any clients on the network with hardcoded DNS.

That should be dealt with by intercepting and redirecting the DNS request. I'm still unsure why you think the response needs masquerading.

I am using DNS forwarding for the LAN, where the PiHole does DNS and DHCP. But the Pi only has settings for one subnet. So I can’t use ‘ignore this interface’ for the IoT subnet since it also needs DHCP. In the IoT DHCP settings I am using DHCP and using option 6 to advertise the Pi for DNS. But the client is under no obligation to use it. Some sneaky manufactures have hard coded DNS in their devices. So I’ve intercepted and redirected all port 53 requests from the IoT to the PiHole.

If a client makes a hard coded DNS request to 8.8.8.8 but gets a response from some other IP address, it will fuss. You can see this with BIND. It will return something like “;;reply from unexpected source: 192.168.3.11#53, expected 8.8.8.8#53” .

PiHole masquerades as the DNS server that the client was trying to reach. Thus the client sits happily quiet getting the intended response. BIND returns a ‘normal’ response.

IoT devices don’t just make an occasional DNS request and then go away if they’re not happy. I have seen on my network that If their not happy with the response, they will hammer away relentlessly at your network with the same request, over and over. This keeps them quiet.

I’ve been using the Pi DNS for a couple of years now with good results and only just now decided to add this option. I added this to keep the hard coded DNS clients happy and quiet.
It seems to be working okay. I know there are other ways of going about things, and I would definitely be interested (and for the sake of other readers) in seeing them.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.