Messages

If I reboot opnsense and I dig opnsense.mydomain.com aaaa, I get no answer.  If I restart unbound manually after boot, then I get expected answer.

This causes me to be unable to access the opnsense web interface from my ipv6 only clients if I reboot the router.

I am not sure what you mean by using Custom DNS, but wouldn't that be better done via unbound?

I also use Spectrum and never had any problems using any upstream DNS I wanted, by using Unbound.

WAN interface:
IPv6 Configuration Type: DHCPv6
Prefix delegation size: 56
Request prefix only: can be checked or not. it provides a unique ipv6 to the WAN interface
Request DNS configuration: I do not check this.
Send prefix hint: checked

LAN interface
Use Identity Association (Track interface is obsolete)
Parent interface: WAN int name
Assign Prefix ID: using VLAN ID in hex
Reserved prefix range: 1
Allow manual adjustment of DHCPv6 and Router Advertisements is no longer there for Identity Association

Services: Router Advertisements
Added an entry for LAN interface
Mode: Unmanaged should be used for Spectrum, otherwise you will have to setup dhcpv6 which isn't recommended for dynamic assigned prefixes
Recursive DNS Servers: Leave blank so it will get from Router

on unbound, under DNS forwarding, set to your 3rd party dns servers, you can use DNS over TLS instead if your 3rd party dns supports it and most do.

With this setup, the network devices will be assigned the router as the local DNS, and your router will then forward to the 3rd party DNS

This really should be one of the top posts. I refer to this constantly for my IPv6 setup.  About the only thing I change and ONLY IF you run a vpn ie wireguard or Tailscale (limit of my personal experience) is the get WAN IPv6. These are a little cleaner if they have a WAN addresses. Otherwise they try to work with the LAN I/f with mixed results.

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?