Messages

I switched Home and Admin such that now Admin uses the untagged network and Home uses tagged network.

Now the problem occured on Admin interface. It looks like this problem is specific to the untagged network.

Hope that generates some interest and suggestions.

I have an interface group with a rule that sends all internet traffic over a gateway ( can be the default or VPN ).

The above rule is setup with FirstMatch disabled so that I can have rules in individual interfaces that can override the gateway.

When I have a rule in one of the member interfaces to redirect traffic from a specific ip address over a different gateway with FirstMatch enabled, I expect the traffic from that specific ip address to be sent over the 2nd gateway while the rest use the first gateway (set in the group rule).

But it doesn't work. The traffic that matches the rule in the interface is rejected or blocked. Many times, traffic from the entire interface containing the override rule is blocked.

This seems to happen quite consistently. I have two instances with the above pattern and both have the same issue.

If the override rule blocks traffic instead of redirecting it over a different gateway, it seems to work as expected.

Is this the way it is supposed to work or is it a bug?

I have OpnSense running on a Proxmox VM with multiple networks. These are not VLANs from OpnSense perspective as Proxmox vnets are used to hide them from OpnSense. In OpnSense they are all separate networks.

I use DNSMasq for DHCP and tried both native as well as separate router advertisements and both have the same problem.

I have IPV6 enabled on three networks - these are ULA addresses used for internal communication.

DMZ (VNET VLAN - one VM on a wired network)
- statically assigned IP4 and IP6 addresses using DHCP and DHCP6.  Slaac is used to generate addl. private outgoing IP6 addresses. (No issues)

Admin (VNET VLAN - fixed/known devices on wifi)
- statically assigned Ip4 and IP6 addresses using DHCP and DHCP6 (no Slaac) (no issues)

Home/LAN (all other devices using WiFi - this is not a VNET but untagged linux bridge created with a physical port on the machine)

All addresses on this network are dynamically assigned by DHCP for IPV4 which works.

In case of IP6, I tried many options (DHCP6, Slaac with Stateless DHCP for DNS address, both). In all cases, address assignment works few times after the changes are made in OpnSense and subsequently stops working.

When I check the log of DNSMasq there is RTR-Advert for the network address but no DHCP-Solicit from the clients after the first few times.

Any suggestions are appreciated.

I tried many times with all variations and I can't find a reason why it happens only on this network.

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.