Messages

Can you paste your NAT rule for comparison?

Here are some screenshots of what works for me (on 26.1.2).  I have Unbound set to listen on All interfaces.  Not shown is the manual pass rule for the NAT rdr that was imported from my legacy ruleset into the new rules UI, but the firewall log shows it passing the traffic.  I use an alias in the NAT rule because I have this VIP referenced in several places.

You cannot view this attachment.




You cannot view this attachment.

You cannot view this attachment.

I am not using virtual IP. My assigned ip to the loopback interface is ULA.

Unbound runs on just this interface as does the Opnsense GUI. I tried the redirection for both Unbound and Opnsense. On Ip4 127.0.0.1 works but nothing works on Ip6.

I tried again. There are no errors in the log but the rule is not firing. I am using "pass" for firewall rule and not an explicit one. That works for Ip4 and not Ip6.

Rule may not be firing because the destination matches with redirect, both ip and ports. That's the case most of the time, the way it is setup. Redirect rule is for safety and pass is used to pass the traffic without explicit filter rule.

This wasn't the case until 25.x.x. Now the rules seem to be ignored when redirect is not needed and because of that pass option is not effective. Explicit rule is needed.

I will test my theory and post later.

Thanks for the screenshots. They are helpful.

I am right. Redirect rules do not fire when destination matches redirect (both port and ip) and the pass option for filter rule is not activated.

That was the issue in my case. I had to add explicit filter rules to allow traffic when there is a possibility of match between and destination and redirect.

Can you paste your NAT rule for comparison?

Here are some screenshots of what works for me (on 26.1.2).  I have Unbound set to listen on All interfaces.  Not shown is the manual pass rule for the NAT rdr that was imported from my legacy ruleset into the new rules UI, but the firewall log shows it passing the traffic.  I use an alias in the NAT rule because I have this VIP referenced in several places.

You cannot view this attachment.




You cannot view this attachment.

You cannot view this attachment.

I am not using virtual IP. My assigned ip to the loopback interface is ULA.

Unbound runs on just this interface as does the Opnsense GUI. I tried the redirection for both Unbound and Opnsense. On Ip4 127.0.0.1 works but nothing works on Ip6.

I tried again. There are no errors in the log but the rule is not firing. I am using "pass" for firewall rule and not an explicit one. That works for Ip4 and not Ip6.

Rule may not be firing because the destination matches with redirect, both ip and ports. That's the case most of the time, the way it is setup. Redirect rule is for safety and pass is used to pass the traffic without explicit filter rule.

This wasn't the case until 25.x.x. Now the rules seem to be ignored when redirect is not needed and because of that pass option is not effective. Explicit rule is needed.

I will test my theory and post later.

Thanks for the screenshots. They are helpful.

You can't use ::1 but the ULA should work.

In my setup I assigned a ULA VIP to the Loopback interface where Unbound also listens, then with a DNAT rule I forward outbound DNS on port 53 to that ULA IP.  Slightly different use case (to trap and redirect unencrypted DNS escapes) but same principle.  Seems to work OK.

My use case is the same but doesn't work for IP6 even with ULA on 26.x.x. It worked until 25.x.x.

Up to 25.x.x, Port Forward to another port on Opnsense worked.

This issue is new in 26.x.x with thd new Dest NAT section.

In my setup unbound runs on a loopback interface (used for Opnsense GUI and few other services) at port 53053.

I am trying to write a Dest NAT rule that redirects all DNS requests (from some VLANs) reaching Opnsense (port 53) to 53053 on the loopback interface.

My ip4 rule works with redirect ip as 127.0.0.1. But I can't figure out the equivalent ip6 address. ::1 doesn't work and neither does the ULA address statically assigned to the interface.

Any suggestions would be appreciated.

Some additional info that may be relevant:

IoT interface is not part of the Interface Group used to redirect traffic to PiHole.

NAT rule redirecting IoT traffic to Unbound is right after the NAT rule redirecting traffic to PiHole.

One question that comes to mind is when the DNAT rules are executed in relation to the firewall filter rules and in what order.

I have been using OpnSense since 2023 and I come to appreciate the effort put into creating such useful and usable software.

I upgraded to 26.1.1 and it is mostly working except I have a few issues with move from the previous port forwarding to Destination NAT.

I understand that the firewall rules have been decoupled from the NAT redirection rules and I took care of updating and moving them into the new rules section.

At this point I have one major issue and other minor ones.

Major issue - redirection seems to completely fail - redirect rule to direct DNS traffic to Unbound for one of the VLANs is ignored as described below.

Primary DNS works as follows:

Client (Interface Group VLANs) -> Pihole (53) -> DNSMAsq (OpnSense: 53) -> External resolver

The above is done using an already existing (still working) DNAT rule that forwards all DNS (53) traffic to PiHole (53) and it seems to continue to work. This is done using an interface group as not all VLANs use PiHole.

For the remaining interfaces/VLANs, DNS works as follows:

Client (remaining VLANs) -> DNSMasq (OpnSense: 53) -> External Resolver

No redirection is used here as DNSMAsq currently runs at port 53 on all interfaces of the OpnSense router. the default DNS address assigned by OpnSense works as is.

The non-working DNAT (redirection) rules is for one of the VLANs (IoT) that uses DNSMsq to use Unbound at 53053 as follows:

DNS Path anticipated:

Client (IoT VLAN) -> Unbound (Opnsense:53053) as recursive resolver

Interface: IoT
Version: IP4/IP6
Protocol: TCP/UDP

Source: any
Source Port: any

Dest: any
Dest Port: 53

Target IP: Numeric IP of the interface where Unbound is running - same as IoT interface on OpnSense
Target port: 53053

I also added a corresponding Firewall rule to allow traffic from IoT VLAN to Unbound (Opnsense 53053).

The issue:

All devices on IoT VLAN still use DNSMasq as ipleak.net shows the external resolver. Using Unbound as recursive resolver should show OpnSense WAN address as the resolver address on ipleak.net.

Conclusion:

The redirection is simply being ignored. If redirection is done but some other problem is causing the traffic not to reach Unboud, DNS should fail and ipleak.net should show DNS errors.

Other minor issues exist which caused other problems but they can wait for another time (there are workarounds).

Any help and guidance will be greatly appreciated.