Destination NAT (port forwarding) issue after upgrade

[EricD]

I was a couple major versions behind, and went through many update/upgrades to get to the newest version.

Destination NAT was working correctly before the upgrade.  Afterwards, it no longer works.

Some details I found that I believe are important:
  1) Destination NAT actually works for a few moments after a full reboot, but then stops working.
  2) Logging shows that the Destination NAT entries, and relevant firewall rules, all trigger and allow passage inward as the requests come in from an external source.
  3) I find no mention of anything being blocked in the logs.

What could the issue be?  What should I be looking at that may be causing the issue?

[jysl]

Are you using multi wan and are you using the new firewall rule or old?

[EricD]

I did have the old rules converted over to the new during the upgrade and had the upgrade process delete the old rules.

I only have one WAN, but do have a semi-permanent VPN, that goes through that WAN, that is used as the external interface for a couple internal networks.  So there are multiple gateways.

[EricD]

Thank you for the question about the multi-wan.  That, along with other posts, finally got my attention to what appears to be the detail I needed to update.

The rule for the WAN interface where the external connection was allowed in had to have "Reply-To" set to the WAN interface.  Once I made that change, the issue appears to be fixed (needs more testing, but it appears to work at the moment).


NOTE: I have my Destination NAT set to where I need to manually make the rules ("Manual").  HOWEVER, in the attempting to fix this issue, I did also try "PASS" and "Register rule", both of which should have theoretically fixed this problem if opnsense was setting its own rules appropriately -- but it did not.  It did not work until I manually changed the rule and set the Reply-to option.

[Bob.Dig]

both of which should have theoretically fixed this problem

Not exactly. Although I am curios how pass is treated without any reply-to. But then, pass is not a "new" rule so it probably has the reply-to still attached.

[LisaMT]

I have a Destination NAT rule on two interfaces to redirect DNS to Opnsense for unbound. 
But it also redirects my camera net which is NOT in the redirect rule.  So all the cameras are sending lots of DNS requests which they don't need. 

[Klabautermann]

Can someone please explain in more detail how the rules need to look when you create them manually. I am experiencing the same issue, upgraded OPNSense, migrated the rules and not I am unable to create a destination NAT. I followed the instruction in the official documentation to set them to pass but it does not work. I also tried to set them to registered and rules appear in the WAN section but it still does not work.

This is super unintuitive and I can't figure it out on my own.

[LisaMT]

I'm still getting port forwarding messages in my log file that claim my 'Camera' network (which should be very isolated) has members trying to reach 8.8.8.8:53. 
The 'Camera' interface is NOT listed in the port forwarding rule.  Only the LAN and PHONE interfaces.  So why do the logs show the rule is acting on the 'Camera' interface? 

[LisaMT]

Seems to still have this issue in 26.1.2_5

[vimage22]

I think "Destination / Invert" should be checked. This is what I use in DNAT for DNS. Notice the "!".

[LisaMT]

I is checked.  See the screen shot.  Today I added a block rule on the CAMERA net and the requests were still happening.  So I disabled that DNAT and of course the redirects from the CAMERA net stopped. 
Seems the DNAT rules ignore what interfaces you have selected.  The CAMERA net should drop everyting by default.
So DNAT rules happen before the other rules, AND ignore what interfaces are checked.

[meyergru]

What does a redirect IP of "This Firewall" even mean? "This firewall" is the set of all adresses the firewall has.

Use an explicit IP like 127.0.0.1 and it will work.

[vimage22]

I cannot answer all of your questions, but I can share what I have noticed so far.
I do not think "!This Firewall" is correct, because it is not the same thing as "!LAN".

I interpret my version of the rule as anything on the LAN, using port 53, trying to get outside of the LAN (e.g. internet) redirects to 127.0.0.1.
I vaguely recall "This Firewall" did not work as expected a long time ago. But I guess it worked for you?

And does traffic on 10.10.25/xx get to the internet, or are you trying to block traffic for that network?

[meyergru]

We have to discriminate some things here. When you look at my NAT rules here (which of course address NTP, not DNS), you will notice three parts vital parts:

1. The interfaces to which the NAT rule should apply. This determines for which of your networks this rule applies. You are free to choose here and that also works for me when I only specify some interfaces.

2. The range of destination IPs and ports that will match. This will be ! (i.e. NOT) "This Firewall", which means: every OTHER DNS server than the firewall itself (regardless of which subnet IP you are referring to) - so it matches any request that does not directly use your firewall, so any external DNS server. Here, it is O.K. to use the set of IPs "This Firewall" to indicate an exclusion. The port would be 53 (DNS) instead of 123 (NTP).

3. The destination IP and port that the request will be redirected to. This must be a single IP, so the set "This Firewall" is plain wrong. You must give a specific target here and you want these requests handled by your firewall, thus, you use 127.0.0.1 to indicate it. The port for DNS also is 53.

[vimage22]

Thank you. That makes sense.