Messages

[Pass]

I recently posted about this issue when I tried to do DNS Redirect with NAT->Port Forward here: https://forum.opnsense.org/index.php?topic=9245.msg198030#msg198030

In that thread, I mentioned that the Rule only works when then Filter Rule Association is set to Pass for all entries that require Destination/Invert

• .
  
  The resulting rule that is created with the Associated/Unassociated are both not able to be edited under the respective interface under the Filter Rule section. Furthermore, the original setting for Destination/Invert
• is NOT carried over to the Filter Rule section for the respective interface so what ends up happening is that it makes it look like the original NAT Rule does not have the Destination/Invert[ ] checked. It should be !DEST but instead it shows up under Filter Rule as regular DEST.
  
  Unassociated Rule under the Full Text Help says that it can be edited separately in the Filter Rule section but that's not the case as it is identical to Associated Rule where it cannot be edited at all.
  
  Only way I got it to work was to set the Filter Rule Association to Pass. This is a loss of functionality for the other two options which has Associated/Unassociated for the aforementioned issues. I might be missing something here as I am a first-time user of OpnSense but the DNS Redirection instructions found here and Reddit or on the Home Network Guy website would not work unless I did what I had to do above.

[Pass]

The original steps in the original guide are outdated at this point and do not work in OpnSense version 24.1.6 (Released on April 18, 2024).

There are a few key issues here which prevent it from working on my system.

1)

Under NAT -> Port Forward -> Create Rule:

Filter Rule Association: Pass

If you try to use Add associated filter rule or Add unassociated filter rule, the filter rules added to your Interface will FAIL because if you look at the rule created, it does not add in the associated Destination/Invert

• from the NAT Rule into the Firewall Rule. You can check by watching the Live Firewall Logs and seeing that the Traffic instead of doing the redirect (rdr) is actually doing the Firewall Rule associated with the NAT Rule.
  
  For me, I named that to be "DNS 53" for the DNS Port 53 forwarding. This will execute when the Conditions of the Firewall Rule for the Interface is met which is the IP or DEST of that rule and if you look at that DEST/IP, it does NOT have the "!" in front of it to be triggered by !DEST and it is actually being triggered by conditions where it is DEST + the desired PORT (DNS)! If you create but not apply or enable a NOT/Destination Invert
• rule under the same interface, you will see that for the Destination column, it will actually show "!" in front of the DEST entered into the Rule and it will also execute when that condition is met.
  
  2) Expansion on #1 re: Filter Rule Association of Associated/Unassociated Rules simply not working. The description says you can edit the Unassociated Rule manually after the NAT rule changes but for both Associated and Unassociated, the respective rule created under the Interface CANNOT be edited at all under any circumstance. This was mentioned here on September 28, 2021: https://forum.opnsense.org/index.php?topic=24905.msg119669#msg119669 where the OP points to the Solution being: https://forum.opnsense.org/index.php?topic=6320.msg26844#msg26844.
  
  Basically, use Pass as the Filter Rule Association and the NAT Rule will execute just fine.
  
  3) You have to check the Live Log or just Firewall Logs in general to see if this is working or not. I constantly tested against this website: https://www.dnsleaktest.com/ after manually setting a Static IP on my smart phone while watching the Firewall Live Log on OpnSense. The moment it started to work correctly, all the DNS other than the local DNS server being used got redirected to the local DNS server and resolved via the DNS servers that I set in AdGuard (QUIC: Adguard, DoH: Quad9).
  
  In the Live Log I'm watching for:
  Actions -> Contains -> rdr
  
  Once it starts to work correctly, that Live Log will start to show entries with the Label "rdr rule" and the respective DEST DNS that the various sources that tried to reach them and the resolution should be via the Local DNS Server specified in the NAT Rule.
  
  Hope this clears up some confusion for individuals who are attempting to do this in May, 2024 and beyond.