Messages

I do have DNS64 enabled but was just surprised that the router itself was using NAT64 internally. It seems to work, was just worried I had misconfigured it.

You will also need firewall rules to allow printing in addition to the MDNS. MDNS just locates the printers address.

I recently installed the os-git-backup for system backup. I created a private repository on GitHub and have it working via SSH to GitHub.

I do have the firewall log outgoing port 22 and I notice that it is going out via the Tayga interface. It works, but that seems odd as the Opnsense router has working IPv4?

There is a bit of discussion over at Netgate. As far as I can tell the action appears to be correct (scrub rule); the logs could be a behavior change in pf.

I believe they should be blocked also, just strange showing in logs.  I thought it might be hardware related and migrated my opnsense VM last night to a different proxmox node, and I still saw them occasionally overnight. Not a huge number in the log so can live with it.

I have started seeing a new entry in the firewall, since updating to 26.7.

Code Select Expand

,,,0,vtnet2,ip-option,block,in,6,0x00,0x00000,1,ip,0,56,::,ff02::16,INVALIDOPT
vtnet2 in my main user lan in this case but have seen on other vlans also.

There is no label in the entry in the Live log. Just protocol IP being blocked with source :: and Destination ff02::16

I have also seen a similar entry but ICMP with same source and destination.

Code Select Expand

,,,0,vtnet4,ip-option,block,in,6,0x00,0x00000,1,icmp,1,56,::,ff02::16,truncated-ip6=56
This is new since the update, and logging is disabled on the default rules.

I am running opnsense virtualized on proxmox.

I opened a bug in GitHub

 Firewall: Rules [new] - Unable to Filter Out Floating rules #10313

[applied to that particular interface]

Yes, the interface views show all floating rules applied to that particular interface, now. A good move, IMHO.

Well I think it's very confusing and inconsistent.

Groups that the interface is a member of are not shown. Confusingly it appears that the float rules occur before the interface rules, when in reality, the Group rules apply after float but before the interfaces.

It was better to use the inspect button, to show all the rules applied to interface in the order they apply, including automatic, float, group and finally the interface.

My filtered Rules (ie WAN, LAN, etc) now always shows the Floating rules also. Is this on purpose or a bug? The group rules only show with inspect button so not consistent?

I prefer to be able to focus on the interface rules I am working on and then check via inspect for Float, and Group rules.

I have the latest OPNsense 26.1.8_5-amd64

Created issue #9966
https://github.com/opnsense/core/issues/9966

I noticed this prior to today's update also.

When I view the firewall rules on my Wireguard Interface, and I select Inspect, I do not see any rules that are in the Wireguard Group. I can see the Automatic rules and the Floating rules.

I can see that the Wireguard group rules are being processed and in the correct order, via Firewall: Diagnostics: Statistics: Rules. It is just not showing in "Inspect"

I don't remember if the old rules did or not. I only have one Wireguard instance so I just moved the group rules to the Interface.

Just an observation.

I've noticed that Interfaces: Neighbors: Discovery is working well in the latest 26.1.2 release.

I briefly tested the feature when it first debuted in January, and I've noticed that those original entries are still present in my Discovered Hosts. Because I am almost entirely IPv6 locally—and thanks to IPv6 Privacy Extensions—my list has ballooned to nearly 700 entries on a relatively small network.

Does the hostwatch database have a mechanism to automatically age out/purge stale entries? Or is manual maintenance required to keep the list from growing indefinitely?

If you try a random IPv6, the Query Forwarding will not kick in. I actually tried a specific IPv6 within a delegated prefix. Then I pinged from that prefix and looked at the live firewall logs. Before I had the query forward, there was a reverse name, after, there was none - but still immediate.

You must get the ip6.arpa domain right, filling up the zeros and not set "forward first".

I tried it again and I'm pretty sure I have the query forwarding setup correctly. I have used it before when I was testing dnsmasq, so I know how to use it.

When I said random address, I mean an address from my prefix. ie I will copy a deprecated address from my Mac, and then do a "dig -x" of that address from a linux client or from opnsense command line. I get a noticeable delay, seconds before I get a response.

Also, in Reporting: Unbound DNS Details tab when I first bring it up, takes a very long time, with the littler spinner until it times out on all of my source addresses (all ipv6).

Putting the local zone static entry in the custom.conf makes all of those actions instant.

It is probably noticeable more for me, since all of my clients are using ipv6.

Have you tried creating a "Query Forwarding" entry with the same reverse domain and 127.0.0.1 / 53 as the Server IP / Port? Works like a charm for me. I think this may even deliver the correct names if you used DHCPv6, but IDK.

I did try this but it did not seem to work for me.  With the Query Forwarding I would dig -x random ipv6 in my prefix, and get:

Code Select Expand

;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out
with query times around 1600ms

I am only using unbound for dns (not dnsmasq) and KEA dhcpv4.

I'm not sure whether this qualifies as a tip or a question, since I couldn't find a way to do this through the web interface.

While debugging an issue with the new firewall logs, I noticed that reverse lookups of my local IPv6 addresses were taking between 800 and 1500 ms each. The reason is that, because my clients use privacy extensions, each lookup (almost never cached) causes Unbound to query my ISP — which owns the address space and hosts the corresponding PTR records.

To address this, I created a file named 1-custom.conf in /usr/local/etc/unbound.opnsense.d with the following content:

Code Select Expand

server:
    # Authoritative reverse zone for my /56
    local-zone: "d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa." static
This tells Unbound that this prefix is part of my local network, preventing it from trying to resolve those reverse lookups externally.

I couldn't find a way to configure this via the web interface, but it seems like a useful feature to have. My ISP assigns a /56, and it has been stable; however, if your ISP frequently changes your prefix, you could apply the same approach to their /48 or even /32 aggregate. In most cases, you won't get meaningful reverse lookups from your ISP for those addresses anyway.