Messages

The traffic shows up in the firewall log on vlan40, as well as on a pcap. Not seeing the same traffic appear on any other interface.
Firewall log

Pcap on macbook

Pcap on vlan40

Hi,
I've noticed some strange behaviour with port forwarding.
Following port forwarding rule is configured:

Interface: vlans 10, 30, 100
IPv4
TCP/UDP
Source: Any
Destination Invert: X
Destination: This Firewall
Destination Port: 53
Target IP: 127.0.0.1
Target Port: 53

What I expect in this case, is that the DNS traffic is redirected on vlans 10,30 and 100 to Unbound with some blocklists, but not on any others.
When I check this, connected to vlan 40 (9.9.9.9 and 2620:fe::fe configured), I see the following result:

IPv6 working fine
❯ dig cloudflare-dns.com a -6

; <<>> DiG 9.10.6 <<>> cloudflare-dns.com a -6
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46859
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;cloudflare-dns.com. IN A

;; ANSWER SECTION:
cloudflare-dns.com. 87 IN A 104.16.248.249
cloudflare-dns.com. 87 IN A 104.16.249.249

;; Query time: 16 msec
;; SERVER: 2620:fe::fe#53(2620:fe::fe)
;; WHEN: Fri Aug 29 09:38:56 CEST 2025
;; MSG SIZE  rcvd: 79

But not IPv4, where traffic is being forwarded to Unbound, even though the rule shouldn't be active on that interface:
❯ dig cloudflare-dns.com a -4

; <<>> DiG 9.10.6 <<>> cloudflare-dns.com a -4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53622
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cloudflare-dns.com. IN A

;; ANSWER SECTION:
cloudflare-dns.com. 3600 IN A 0.0.0.0

;; Query time: 90 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Fri Aug 29 09:38:02 CEST 2025
;; MSG SIZE  rcvd: 63

Only when I configure a source with the vlan 10, 30 and 100 subnets in the port forward rule, it doesn't redirect the DNS traffic to unbound:
❯ dig cloudflare-dns.com a -4

; <<>> DiG 9.10.6 <<>> cloudflare-dns.com a -4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27779
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;cloudflare-dns.com. IN A

;; ANSWER SECTION:
cloudflare-dns.com. 290 IN A 104.16.249.249
cloudflare-dns.com. 290 IN A 104.16.248.249

;; Query time: 96 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Fri Aug 29 09:40:29 CEST 2025
;; MSG SIZE  rcvd: 79

Is this normal and/or am I missing something? I don't think a source would have to be configured, since you make a selection of interfaces where this rule should be applied.

It always works after a reboot, but it comes back after a while, no matter which browser I use.
Every day the graph seem to move a little to the left...

Same issue.
Tested using Firefox, Chrome and Safari on Mac OS X 14.5

Applied the patch, seems to be working in my case.
Attached a screenshot of my settings.
Let me know if you need further details or testing done.

Hi, any news on this?

KEA hands out a different IP than the one configured in the reservations:



This happened after replacing the sdcard in my pi en restarting it.
Anyone experience something similar or know what the cause might be?

It looks like ddclient is as good as dead... Unless someone takes over the project...
https://github.com/ddclient/ddclient/issues/528

Hi,
Thanks for looking in to this.
I'm not sure I understand what I should report to ddclient?
ddclient updates the cloudflare dns record and seems to work fine as far as I can see:
2023-03-11T06:51:27   Notice   ddclient[7241]   9078 - [meta sequenceId="1"] SUCCESS: updating my.domain.com: IPv4 address set to x.x.x.x

The issue I raised for duckdns has been merged, so this should be included in the next release: https://github.com/ddclient/ddclient/pull/506

Sometimes (but not always) unbound tries to download the blocklists too soon, I had the same issue: https://forum.opnsense.org/index.php?topic=32327.0
If you look at your Unbound logs (Services: Unbound DNS: Log File), you should see messages that the download failed because a connection could not be established. Can you check?
I was under the impression that this was fixed, maybe @Fright can chime in?

I've opened an issue on github for this: https://github.com/opnsense/core/issues/6407

I've opened an issue on github for this: https://github.com/opnsense/core/issues/6407

Issue has been opened: https://github.com/opnsense/core/issues/6402

Not sure what happened, but I've rebooted twice now and this is my latest log.
Does seem to work, I'm not getting any errors.

Hey, I've only just got around to testing, been a few busy days at work.
This seems to have fixed it for me. I can see in the logs that, if the blocklists aren't downloaded, there's a retry.
Rebooted 3 times, and every time the lists are downloaded, so for me the issue is fixed.
Thanks for looking into this!