opnsense / core

OPNsense GUI, API and systems backend
https://opnsense.org/
BSD 2-Clause "Simplified" License
3.32k stars 739 forks source link

NAT redirect rules don't respect interface selection and instead rely solely on source address #7952

Open Unspec7 opened 1 week ago

Unspec7 commented 1 week ago

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

Describe the bug

I have a couple of internet NAT redirect rules, specifically to enforce my pihole DNS for my IOT devices, since Google Homes hardcode google DNS. I noticed that despite only wanting to enforce it on the IOT network, it was being enforced on all networks, despite selecting interface as "IOT".

Turns out, this was due to the fact that source was set to "ANY". So it appears that NAT redirects, if source is ANY, completely ignore the set interface and matches all traffic with that rule. This has firewall implications because it can inadvertently allow certain devices on an interface to bypass a firewall rule on that interface due to the unintended redirect. It also makes it impossible to create a single redirect rule that applies to multiple interfaces without creating an interface group.

Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)

To Reproduce

Steps to reproduce the behavior (note: using DNS redirect for ease of testing):

  1. Create NAT redirect rule targeting interface A, with source any, port any, destination NOT your local DNS, and target your local DNS.
  2. Create a firewall block rule on interface B that blocks DNS requests to 9.9.9.9
  3. On a device on interface B, run dig [something.com] @9.9.9.9 3a. Result: DNS still goes though
  4. Set NAT redirect rule in step 1 to have source "Interface A net"
  5. On a device on interface B, run dig [something.com] @9.9.9.9 5a. Result: DNS blocked properly

Expected behavior

  1. Create NAT redirect rule targeting interface A, with source any, port any, destination NOT your local DNS, and target your local DNS.
  2. Create a firewall block rule on interface B that blocks DNS requests to 9.9.9.9
  3. On a device on interface B, run dig [something.com] @9.9.9.9 3a. Result: DNS blocked properly due to NAT redirect rule only applying to interface A
  4. Set NAT redirect rule in step 1 to have source "Interface A net"
  5. On a device on interface B, run dig [something.com] @9.9.9.9 5a. Result: DNS blocked properly.

Describe alternatives you considered

Using interface net as the source, but as mentioned before, this is not ideal since it forces you to create interface groups.

Screenshots

NAT redirect rule for pihole: image

Log live view RDR: image

DMZ firewall rules. Second rule doesn't apply even though it should since the redirect shouldn't be redirecting DMZ network traffic: image

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 24.7.5_3-amd64

ollioddi commented 6 days ago

Have the exact same issue. It completely grabs anything.

Unspec7 commented 5 days ago

The current more elegant workaround, other than to make a bunch of firewall interface groups, is to create firewall network aliases with the relevant networks placed in them.

Still not great, but working as a temporary workaround.