"
Following up on my own post — @OPNenthu was right, and my IPv4 observation was wrong. Posting the correction in case anyone finds this thread later.
Short version: the redirect was working the whole time, but not for the reason I thought. The inverted firewall rule was not the thing passing redirected traffic.
The mechanism is that opnsense translates before it filters. By the time the filter rules are evaluated, a redirected packet's destination is already the redirect target. So the associated pass rule needs to match the target, not the original destination.
My IPv4 filter rule was destination = !127.0.0.1, port 53, on the interface group. That excludes precisely the packets it was supposed to be passing. What it actually matched was port 53 traffic aimed at my own local addresses — clients querying the firewall's LAN IP directly — which is exactly the traffic the NAT rule deliberately skips. The redirected packets were being passed further down by my ordinary allow-any LAN rule.
Confirmed with logging. Pointing a client at an external resolver produced an rdr line in the firewall log, and the query showed up in Unbound as expected — but there was no corresponding pass line from my manual rule, which had logging enabled. It was never matching.
Why IPv6 looked different: same construction, different outcome. The IPv4 target is 127.0.0.1, which falls outside the negated set, so the inverted rule matched and looked load-bearing. The IPv6 target is a ULA VIP, which falls inside the negated set, so the same rule visibly failed to match. One mechanism, two results — not an inconsistency in OPNsense.
I also suspect what I read as "unchecking invert breaks the IPv4 redirect" was actually the loss of DNS to the firewall's own LAN address. Clients pointed at the gateway for DNS would break in a way that looks identical to a broken redirect from the client side.
The fix was to stop hand-writing the filter rules entirely: set the NAT rule's Firewall rule option to Register and let OPNsense generate the associated rule (destination = the redirect target, not inverted). Verified working on both protocols now, with no asymmetry between them.
@meyergru's point stands and is the one genuine IPv4/IPv6 difference here — the IPv6 redirect target has to be routable, hence a ULA VIP rather than ::1. I had that part right already, which is why the v6 side worked.
Apologies for the noise, and thanks to both of you for the pushback.
Short version: the redirect was working the whole time, but not for the reason I thought. The inverted firewall rule was not the thing passing redirected traffic.
The mechanism is that opnsense translates before it filters. By the time the filter rules are evaluated, a redirected packet's destination is already the redirect target. So the associated pass rule needs to match the target, not the original destination.
My IPv4 filter rule was destination = !127.0.0.1, port 53, on the interface group. That excludes precisely the packets it was supposed to be passing. What it actually matched was port 53 traffic aimed at my own local addresses — clients querying the firewall's LAN IP directly — which is exactly the traffic the NAT rule deliberately skips. The redirected packets were being passed further down by my ordinary allow-any LAN rule.
Confirmed with logging. Pointing a client at an external resolver produced an rdr line in the firewall log, and the query showed up in Unbound as expected — but there was no corresponding pass line from my manual rule, which had logging enabled. It was never matching.
Why IPv6 looked different: same construction, different outcome. The IPv4 target is 127.0.0.1, which falls outside the negated set, so the inverted rule matched and looked load-bearing. The IPv6 target is a ULA VIP, which falls inside the negated set, so the same rule visibly failed to match. One mechanism, two results — not an inconsistency in OPNsense.
I also suspect what I read as "unchecking invert breaks the IPv4 redirect" was actually the loss of DNS to the firewall's own LAN address. Clients pointed at the gateway for DNS would break in a way that looks identical to a broken redirect from the client side.
The fix was to stop hand-writing the filter rules entirely: set the NAT rule's Firewall rule option to Register and let OPNsense generate the associated rule (destination = the redirect target, not inverted). Verified working on both protocols now, with no asymmetry between them.
@meyergru's point stands and is the one genuine IPv4/IPv6 difference here — the IPv6 redirect target has to be routable, hence a ULA VIP rather than ::1. I had that part right already, which is why the v6 side worked.
Apologies for the noise, and thanks to both of you for the pushback.
