Messages

The only way I can get the ULA DNS address advertised (and only the ULA, not the GUA) is to make it the only 'dns-server [23]' option for the interface and delete the blank ones for the GUA ranges.

In this case though, the tags aren't doing anything and can also be deleted.

Code Select Expand

$ resolvectl status
...
Current DNS Server: 172.21.30.1
       DNS Servers: 172.21.30.1 fd7b:1236:9970:1003::1
        DNS Domain: clear.h1.internal

What I was hoping to achieve is some distinction between the prefixes so that I could set options on them separately (e.g. use the ULA range as DHCPv6 only and the GUA one as RA only).  But now I'm not even sure that's practical.  Maybe clients would just use one or the other.

How do you do this kind of split ULA/GUA addressing in the real world where there is no static IPv6 prefix from the ISP that can be configured without needing a constructor on the range?  Is it possible?

My best alternative plan to avoid dynamic IPv6 quirks (+others I've experienced) is to just give in to ULA addressing only within my network and NPTv6 for outbound, similar (though not the same) as what @Javier® posted here: https://forum.opnsense.org/index.php?topic=51376.msg263307#msg263307.  I tried it and it works, but of course the browser mostly prefers IPv4 in that case.  It's a little bit of a step backwards in terms of overhead (IPv4 NAT is mostly still used) and privacy (everything again NATed to a single address vs. hosts with regularly changing randomized host bits when privacy extensions are active).  But it's stable.

If it's the timeout issue, then no need to reboot.  OPNsense is fine and it's just the web session that's gone stale.

Hit the browser refresh and log in again.

(And here I am again to drop some YT links... :P)

On the Mythos AI topic, I wonder if I might have bitten on the hype a little too soon.  I caught an episode on the Internet of Bugs channel that seems grounded.  Anybody follow him?

@chemlud the type of societal structures and systems-level thinking you refer to is something I have been learning about lately.  Highly recommend to watch the Nate Hagens channel for his theories on what lies ahead of us (what he calls "The Great Simplification").  Second, third, fourth order effects of having exhausted our one-time planetary endowment of fossil fuel that nobody in the public sphere is talking about... and certainly nobody in business.  But it's coming.

Thanks @nero355, I appreciate you letting me pick your brain a bit.

If I'm not mistaken, Android doesn't support DHCPv6.  Not sure if that's changed in recent versions.

I'm convinced that tech CEOs and all the finance people undergo mandatory training on how to leave reality and join shareholders in an imagined dreamland of infinite growth...

It must take a lot of drugs to get there.

[-O, --dhcp-option=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-name>|option6:<opt>|option6:<opt-name>],[<value>[,<value>]]]

I'm trying an experiment to assign both GUA and ULA ranges in Dnsmasq, but to logically separate them with DHCP tags.  The idea is to let clients auto-configure IPs on both ranges, one for stable internal IPv6 networking, and one for internet access.  Since I have a dynamic ISP prefix, I want to exclude any DNS assignment on the GUA range and offer only a ULA address for Unbound in Dnsmasq RAs (RDNSS).

As per the Dnsmasq manual, we should be able to override the default option which sets the OPNsense interface address as the DNS by setting the option with an empty value:

-O, --dhcp-option=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-name>|option6:<opt>|option6:<opt-name>],[<value>[,<value>]]
...
An option without data is valid, and includes just the option without data. (There is only one option with a zero length data field currently defined for DHCPv4, 80:rapid commit, so this feature is not very useful in practice). Options for which dnsmasq normally provides default values can be omitted by defining the option with no data. These are netmask, broadcast, router, DNS server, domainname and hostname. Thus, for DHCPv4 --dhcp-option = option:router will result in no router option being sent, rather than the default of the host on which dnsmasq is running. For DHCPv6, the same is true of the options DNS server and refresh time.

So I tried this-

On each of my VLANs I used a tagged 'xGUA' range with the interface constructor (constructor=LAN) and a second tagged 'xULA' range with the ULA that I defined in VIP configs (constructor=None).

Then in DHCP options I offered the OPNsense ULA address as the DNS on the 'xULA' range and I overrode the DNS with a blank value for the 'xGUA' range, as the manual says I can do.

You cannot view this attachment.

You cannot view this attachment.


What works:

- The SLAAC addressing is fine.  Clients are configuring themselves with IPs on both ranges.

What fails:

- Clients are still getting the OPNsense GUA interface address as the IPv6 DNS.

Code Select Expand

$ ip a
...
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
    link/ether <redacted> brd ff:ff:ff:ff:ff:ff
    inet 172.21.30.100/24 brd 172.21.30.255 scope global dynamic noprefixroute enp6s0
       valid_lft 86248sec preferred_lft 86248sec
    inet6 fd7b:1236:9970:1003:e717:cc84:66e1:d8f3/64 scope global temporary dynamic
       valid_lft 86357sec preferred_lft 85901sec
    inet6 fd7b:1236:9970:1003:44df:603e:214c:824f/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86357sec preferred_lft 86357sec
    inet6 26xx:xx:xxxx:3163:a54b:860e:9bf9:3109/64 scope global temporary dynamic
       valid_lft 86357sec preferred_lft 85901sec
    inet6 26xx:xx:xxxx:3163:xxxx:xxxx:xxxx:xxx/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86357sec preferred_lft 86357sec
    inet6 fe80::xxxx:xxxx:xxx:xxxx/64 scope link noprefixroute
       valid_lft forever preferred_lft forever


Code Select Expand

$ resolvectl status
Current DNS Server: 172.21.30.1
       DNS Servers: 172.21.30.1 26xx:xx:xxxx:3163::1
        DNS Domain: clear.h1.internal

I expected to see an fd7b:...::1 address here ^.

Anybody know what I missed?

Are you sure it's not a False Positive ?!

Today it's working, so either the node was removed from a list I am using, or I got routed to a different one this time.  It's very rare for that to happen so that's why I was surprised.

I guess this also illustrates the difficultly with DoH filtering.  Any servers that are found to provide DNS get added to the list, but in some cases those same IPs serve other purposes and/or web content.  So you have a tough choice: unblock or not.

In fact when Pi-hole v6.x.x got released somewhere around February 2025 I was seriously 'STOKED!' as they say :
- No more LigHTTPd.
- No more PHP.
- CivetWeb does almost everything now and is part of the whole FTLDNS package.
- C++ is now the way forward.
- DNSmasqd is ofcourse still part of FTLDNS.
- The API is also still available.
- Super Sweet New webGUI that's a 1:1 translation of the pihole.toml config file which is in a league of it's own when you see how nicely commented it is via SSH when you edit it via nano or vi :)

Good updates, although what's curiously still missing from the list is native DoT forwarder support in Unbound.  I get this out of the box with OPNsense (no custom add-ons like 'stubby' or 'dnscrypt-proxy' needed).

IIRC, the devs have a philosophy that recursive resolution with Unbound is the best thing since sliced bread and not worth using anything else.  They must be EU based and trust their ISP not to hoover plain DNS over the wire (or they tunnel it) :)

Serious question: what's the killer functionality of Pi-hole that Unbound in OPNsense (as of 26.1) doesn't have?  Besides, I guess, data retention period for reports which is rather limited in OPNsense.

@cunfused_kiwi quick correction: I checked my own WG setup and I am also using the "Disable routes" option there.  Sorry about that.

These are your rules reconstructed with AI as pseudo-pf from the XML, in sequence order.  Just easier to read.

Code Select Expand

pass in quick on opt2 inet proto { tcp udp } \
    from <Mullvad_VPN_Clients> to any port 53 \
    keep state \
    route-to (opt2 Mullvad_VPN_Gateway)

pass in quick on opt2 inet from <Mullvad_VPN_Clients> to any \
    keep state \
    route-to (opt2 Mullvad_VPN_Gateway)

Not pertinent to your issue, but worth mentioning-

The DNS rule is redundant.  Your second rule anyway routes all IPv4 traffic from the VPN clients to the Mullvad gateway.

While troubleshooting I checked "Disable routes" in the WireGuard Instance and the Internet everywhere worked again, but DNS for the Hosts routed trough Mullvad didn't work anymore

This is just a guess...

Try leaving "Disable routes" unchecked (the default) but make sure that you have rules in place to allow (or route) the other clients to the normal WAN gateway.  Without such a rule they will not have egress.

If that's the cause then I think you might also notice a lot of "Default deny / state violation rule" blocks in the firewall live log for the clients which are not in the alias.

- Or you could use Pi-Hole + Unbound the way it's explained here : https://docs.pi-hole.net/guides/dns/unbound/

Their main website (https://pi-hole.net/) get blocked on my end by a DoH IP list.  Looks like a CDN domain (*.b-cdn.net) according to uBlock origin and it has a high abuse score to boot:

https://www.ipqualityscore.com/free-ip-lookup-proxy-vpn-test/lookup/37.19.207.37

I've used Pi-Hole in the past and wanted to experiment with it again in a Proxmox container, but I don't want to whitelist these IPs.  Not a good look for a privacy-focused DNS project :-/

No issue with their GitHub repo, though.

As I haven't used Pi-Hole in years and haven't followed the project, do you still find them trustworthy now in 2026?  Any concerning developments or money ties?

Indeed, thanks for those links.

Understood and thanks, though my last post wasn't arguing for inclusion.  The arguments against are convincing enough :)

Admins and developers who don't prioritize privacy or censorship resistance may not find this significant.

Tools have a place and it's good to have options (whether in OPNsense or not), but we should be clear that resistance is a political process.  Just evading blocks isn't going to effect meaningful change.

Also, AIUI states are tied to direction as well as interface. So perhaps, even with states not bound to interfaces, packet are associated with both an ingress an egress state.

You might be right about the in/out states.  I guess it should be evident from the session information in OPNsense.  The question though: even if there's a separate state for the egress, the killswitch rule might not be activated if the state is floating.