"Recent posts
#1
Web Proxy Filtering and Caching / Nginx and opnsense.domain "Ser...
Last post by danman - Today at 03:08:11 AMHey
I'm currently setting up opnsense with nginx.
I've already set up ACME which works fine and now I'm trying to use opnsense.domain instead of 192.168.20.1:10443.
Which means I changed GUI port to 10443 and disabled web gui redirect. I deleted LAN and created a bunch of VLANs and 192.168.20.1 is one of it.
I created an upstream server (not mentioned options means defaults):
upstream
Location
HTTP Server
The error is:
I didin't do anything with Naxsi if it is related to that?
Hope someone can push me to the right direction.
I'm currently setting up opnsense with nginx.
I've already set up ACME which works fine and now I'm trying to use opnsense.domain instead of 192.168.20.1:10443.
Which means I changed GUI port to 10443 and disabled web gui redirect. I deleted LAN and created a bunch of VLANs and 192.168.20.1 is one of it.
I created an upstream server (not mentioned options means defaults):
Code Select
Description opnsense.domain
Server 192.168.20.1
Port 10443
Server Priority 1
upstream
Code Select
Description opnsense.domain
Server Entries opnsense.domain
Enable TLS (HTTPS) enabled
Location
Code Select
Description opnsense.domain
URL Pattern /
Upstream Servers opnsense.domain
Force HTTPS enabled
HTTP Server
Code Select
HTTP Listen Address 80
HTTPS Listen Address 443
Server Name opnsense.domain
Locations opnsense.domain
TLS Certificate opnsense.domain (ACME Client)
HTTPS Only enabled
The error is:
Code Select
Server Error
Sorry, but something went wrong on our side.
There is nothing you can do except waiting until we fix the issue.
Web Application Protection by OPNsense
OPNsense Logo I didin't do anything with Naxsi if it is related to that?
Hope someone can push me to the right direction.
#2
German - Deutsch / Re: Eingehende WAN-Anfragen: R...
Last post by Patrick M. Hausen - Today at 12:19:25 AMIch verstehe, weshalb das ein sinnvolles Feature ist. Ich verstehe nicht, weshalb "enabled" der Default ist.
OPNsense an einem DSL-Anschluss oder irgend einem Point-to-Point Link - alles cool und froody.
OPNsense in einem Lab, WAN und LAN RFC-Netze, nix funktioniert, Leute schlagen im Forum auf.
Reply-to braucht man nur bei zwei oder mehr WAN-Links. Und dann sollte man wissen, was man tut.
Wäre sehr für eine Änderung des Defaults.
OPNsense an einem DSL-Anschluss oder irgend einem Point-to-Point Link - alles cool und froody.
OPNsense in einem Lab, WAN und LAN RFC-Netze, nix funktioniert, Leute schlagen im Forum auf.
Reply-to braucht man nur bei zwei oder mehr WAN-Links. Und dann sollte man wissen, was man tut.
Wäre sehr für eine Änderung des Defaults.
#3
German - Deutsch / Re: Eingehende WAN-Anfragen: R...
Last post by OPNdaniel - Today at 12:15:46 AMBesten Dank Patrick, genau das war es! 😊
#4
German - Deutsch / Re: Eingehende WAN-Anfragen: R...
Last post by Patrick M. Hausen - Today at 12:03:21 AMFirewall > Settings > Advanced > Disable reply-to.
#5
German - Deutsch / Eingehende WAN-Anfragen: Rückr...
Last post by OPNdaniel - Today at 12:01:02 AMHallo zusammen,
aktuell habe ich ein seltsames Problem, das ich gerade noch nicht so ganz nachvollziehen kann und bitte um Unterstützung diesbezüglich.
Hier der Netzwerkaufbau zur Übersicht:
You cannot view this attachment.
Mein Vorhaben:
Ich möchte vom Laptop aus auf den Server zugreifen (z.B. anpingen), der hinter einer OPNsense-Firewall sitzt (das ganze ist eine reine Testumgebung, daher in diesem Fall der Zugriff vom WAN-Interface kommend).
Am Laptop wurde eine statische Route definiert, die für Anfragen an IP-Adressen des opt1 networks (in dem sich der Server befindet) die WAN-Schnittstelle der OPNsense-Firewall als Next Hop verwendet.
Eine Firewall-Regel, die am WAN-Interface eingehende ICMP-Anfragen aus dem WAN network (in dem sich der Laptop befindet) mit dem Ziel opt1 network (in dem sich der Server befindet), erlauben würde, habe ich ebenfalls erstellt.
Beim WAN-Interface der OPNsense-Firewall wurde die Funktion "Block private networks" abgehakt/deaktiviert.
Das Problem:
Allerdings erhalte ich auf dem Laptop für die Pings eine Zeitüberschreitung. Interessehalber habe ich am Server einen Wireshark-Trace gestartet und festgestellt, dass die eingehenden ICMP-Anfragen dort ankommen und auch beantwortet werden würden (IP-Adressen stimmen auch), jedoch kommt die Antwort nicht mehr am Laptop an.
Und hier kann ich im Moment nicht nachvollziehen, weshalb dies so ist. Das interessante dabei: Wenn ich in OPNsene die Firewall-Funktion mittels "pfctl -d" deaktiviere, kommen die Antworten am Laptop plötzlich an; wenn ich sie mittels "pfctl -e" wieder aktiviere, bleiben die Antworten wieder aus.
Im Live View der angewendeten Regeln gibt es sowohl einen positiven Eintrag für die eingehende ICMP-Anfrage am WAN-Interface als auch für den Ausgang am Interface opt1 ("let out anything from firewall host itself"). Hinweise, weshalb die Rückroute scheitert, konnte ich dort bisher keine ausfindig machen.
Hat jemand von euch eine Idee, woran es liegen könnte?
PS: Inter-Interface-Routing und -Firewall-Regeln, Zugriff nach WAN/Internet etc. funktioniert alles, hier habe ich schon unzählige Regeln geschrieben. Nur diese eine möchte nicht so Recht funktionieren und ich befürchte, dass ich gerade einfach "auf dem Schlauch stehe"...
Vielen Dank im Voraus für eure Unterstützung und viele Grüße
Daniel
aktuell habe ich ein seltsames Problem, das ich gerade noch nicht so ganz nachvollziehen kann und bitte um Unterstützung diesbezüglich.
Hier der Netzwerkaufbau zur Übersicht:
You cannot view this attachment.
Mein Vorhaben:
Ich möchte vom Laptop aus auf den Server zugreifen (z.B. anpingen), der hinter einer OPNsense-Firewall sitzt (das ganze ist eine reine Testumgebung, daher in diesem Fall der Zugriff vom WAN-Interface kommend).
Am Laptop wurde eine statische Route definiert, die für Anfragen an IP-Adressen des opt1 networks (in dem sich der Server befindet) die WAN-Schnittstelle der OPNsense-Firewall als Next Hop verwendet.
Eine Firewall-Regel, die am WAN-Interface eingehende ICMP-Anfragen aus dem WAN network (in dem sich der Laptop befindet) mit dem Ziel opt1 network (in dem sich der Server befindet), erlauben würde, habe ich ebenfalls erstellt.
Beim WAN-Interface der OPNsense-Firewall wurde die Funktion "Block private networks" abgehakt/deaktiviert.
Das Problem:
Allerdings erhalte ich auf dem Laptop für die Pings eine Zeitüberschreitung. Interessehalber habe ich am Server einen Wireshark-Trace gestartet und festgestellt, dass die eingehenden ICMP-Anfragen dort ankommen und auch beantwortet werden würden (IP-Adressen stimmen auch), jedoch kommt die Antwort nicht mehr am Laptop an.
Und hier kann ich im Moment nicht nachvollziehen, weshalb dies so ist. Das interessante dabei: Wenn ich in OPNsene die Firewall-Funktion mittels "pfctl -d" deaktiviere, kommen die Antworten am Laptop plötzlich an; wenn ich sie mittels "pfctl -e" wieder aktiviere, bleiben die Antworten wieder aus.
Im Live View der angewendeten Regeln gibt es sowohl einen positiven Eintrag für die eingehende ICMP-Anfrage am WAN-Interface als auch für den Ausgang am Interface opt1 ("let out anything from firewall host itself"). Hinweise, weshalb die Rückroute scheitert, konnte ich dort bisher keine ausfindig machen.
Hat jemand von euch eine Idee, woran es liegen könnte?
PS: Inter-Interface-Routing und -Firewall-Regeln, Zugriff nach WAN/Internet etc. funktioniert alles, hier habe ich schon unzählige Regeln geschrieben. Nur diese eine möchte nicht so Recht funktionieren und ich befürchte, dass ich gerade einfach "auf dem Schlauch stehe"...
Vielen Dank im Voraus für eure Unterstützung und viele Grüße
Daniel
#6
Development and Code Review / Re: Zabbix >=7.0 template for ...
Last post by wbond - August 15, 2026, 10:24:36 PMHi @Garfieldttt
Thanks for this, evaluating it now!
regards
Thanks for this, evaluating it now!
regards
#7
Tutorials and FAQs / Remote OPNsense serial console...
Last post by ProximusAl - August 15, 2026, 10:12:32 PMI have an OPNsense DEC750v2 which is a truly headless appliance. There are no HDMI, DisplayPort or VGA outputs - local console access is via the Mini-USB serial console port.
Normally this isn't a problem, but it becomes more important when something goes wrong during an upgrade. If OPNsense won't boot properly and both the WebGUI and SSH are unavailable, the serial console may be the only way to see what is happening and interact with the boot loader.
This is particularly relevant now that OPNsense supports ZFS snapshots/boot environments. I can create a snapshot before an upgrade, but if the upgrade goes badly enough that OPNsense is inaccessible, I still need some way of reaching the console to select and boot the previous environment.
I wanted a way of accessing that serial console without having to physically connect a laptop to the DEC750v2 every time.
I already had a QNAP NAS sitting next to the firewall, so I used Container Station/Docker to turn it into a simple network-accessible serial console server.
The setup is:
DEC750v2 Mini-USB console
|
v
QNAP /dev/ttyACM0
|
v
Docker container (Alpine)
|
+--- ser2net TCP 7001 ---> PuTTY (Raw TCP)
|
+--- ttyd TCP 7681 ------> Web browser
OPNsense configuration
In OPNsense I went to:
System -> Settings -> Administration -> Console
and configured:
Primary Console: Serial Console
Secondary Console: EFI Console
Serial Speed: 115200
USB-based serial: Disabled
Console menu: Password protect enabled
Once saved, the normal OPNsense console menu became available over the DEC750v2 serial connection.
QNAP configuration
I connected the DEC750v2 Mini-USB console port to a USB port on the QNAP.
On the QNAP this appeared as:
/dev/ttyACM0
I created the following directory:
/share/Container/opnsense-console
In that directory I created a file called:
Dockerfile
Containing:
FROM alpine:3.24
RUN apk add --no-cache ser2net ttyd netcat-openbsd
COPY ser2net.yaml /etc/ser2net.yaml
CMD sh -c 'ser2net -n -c /etc/ser2net.yaml & exec ttyd -W -p 7681 nc 127.0.0.1 7001'
I then created:
ser2net.yaml
Containing:
connection: &opnsense
accepter: tcp,7001
enable: on
connector: serialdev,/dev/ttyACM0,115200n81,local
I built the Docker image with:
cd /share/Container/opnsense-console
sudo docker build --pull --no-cache -t opnsense-console:latest .
Then created the container:
sudo docker run -d \
--name opnsense-console \
--restart unless-stopped \
--device=/dev/ttyACM0:/dev/ttyACM0 \
-p 7001:7001 \
-p 7681:7681 \
opnsense-console:latest
The "--restart unless-stopped" option means the console container automatically comes back after the QNAP reboots.
PuTTY access
I can connect using PuTTY with:
Host: QNAP-IP
Port: 7001
Connection type: Raw
This gives me the normal interactive OPNsense serial console through PuTTY.
Web console
I also added ttyd to provide a proper browser-based terminal.
This is accessed using:
http://QNAP-IP:7681
I always use IP because OPNSense is my DNS server too...
This works particularly well from Safari on an iPad/iPhone and gives me a proper interactive terminal with the normal on-screen keyboard.
Both methods ultimately connect to the same serial console:
PuTTY -> TCP 7001 -> ser2net -> /dev/ttyACM0 -> DEC750v2
or:
Browser -> ttyd -> netcat -> ser2net -> /dev/ttyACM0 -> DEC750v2
Why I wanted this
My main reason for doing this is safer OPNsense upgrades.
Before upgrading I can create a ZFS snapshot/boot environment.
If an upgrade then breaks OPNsense badly enough that the WebGUI and SSH aren't available, I still have access to the physical serial console.
The particularly useful part is that the serial connection is available throughout a reboot. This means I can see the DEC/FreeBSD boot process and interrupt the boot loader if necessary.
I can therefore reboot the DEC, interrupt the FreeBSD loader and select the previous ZFS boot environment without having to physically connect another machine to the firewall.
Obviously this isn't true out-of-band management because the QNAP is still accessed over my normal LAN. However, my network is a flat LAN and devices retain their IP addresses while the firewall is rebooting or unavailable.
This means I can still access another machine on the LAN by IP and from there access the QNAP console server even if OPNsense itself isn't working.
Security
There are a couple of important security considerations.
TCP 7001 is raw, unencrypted and unauthenticated.
The basic ttyd configuration on TCP 7681 is also HTTP and unauthenticated.
I only expose these on my trusted internal LAN.
I would absolutely not port-forward either of these ports or expose them directly to the Internet.
I also have password protection enabled on the OPNsense console menu itself.
Other hardware
Although I happened to use a QNAP NAS, there's nothing particularly QNAP-specific about the actual solution.
Any always-on machine capable of running Docker and accessing the USB serial device should be able to do essentially the same thing.
For me it's effectively turned an existing NAS sitting next to the firewall into a small dedicated OPNsense console server, with both PuTTY and browser access.
I hope this might help or inspire someone else...
Normally this isn't a problem, but it becomes more important when something goes wrong during an upgrade. If OPNsense won't boot properly and both the WebGUI and SSH are unavailable, the serial console may be the only way to see what is happening and interact with the boot loader.
This is particularly relevant now that OPNsense supports ZFS snapshots/boot environments. I can create a snapshot before an upgrade, but if the upgrade goes badly enough that OPNsense is inaccessible, I still need some way of reaching the console to select and boot the previous environment.
I wanted a way of accessing that serial console without having to physically connect a laptop to the DEC750v2 every time.
I already had a QNAP NAS sitting next to the firewall, so I used Container Station/Docker to turn it into a simple network-accessible serial console server.
The setup is:
DEC750v2 Mini-USB console
|
v
QNAP /dev/ttyACM0
|
v
Docker container (Alpine)
|
+--- ser2net TCP 7001 ---> PuTTY (Raw TCP)
|
+--- ttyd TCP 7681 ------> Web browser
OPNsense configuration
In OPNsense I went to:
System -> Settings -> Administration -> Console
and configured:
Primary Console: Serial Console
Secondary Console: EFI Console
Serial Speed: 115200
USB-based serial: Disabled
Console menu: Password protect enabled
Once saved, the normal OPNsense console menu became available over the DEC750v2 serial connection.
QNAP configuration
I connected the DEC750v2 Mini-USB console port to a USB port on the QNAP.
On the QNAP this appeared as:
/dev/ttyACM0
I created the following directory:
/share/Container/opnsense-console
In that directory I created a file called:
Dockerfile
Containing:
FROM alpine:3.24
RUN apk add --no-cache ser2net ttyd netcat-openbsd
COPY ser2net.yaml /etc/ser2net.yaml
CMD sh -c 'ser2net -n -c /etc/ser2net.yaml & exec ttyd -W -p 7681 nc 127.0.0.1 7001'
I then created:
ser2net.yaml
Containing:
connection: &opnsense
accepter: tcp,7001
enable: on
connector: serialdev,/dev/ttyACM0,115200n81,local
I built the Docker image with:
cd /share/Container/opnsense-console
sudo docker build --pull --no-cache -t opnsense-console:latest .
Then created the container:
sudo docker run -d \
--name opnsense-console \
--restart unless-stopped \
--device=/dev/ttyACM0:/dev/ttyACM0 \
-p 7001:7001 \
-p 7681:7681 \
opnsense-console:latest
The "--restart unless-stopped" option means the console container automatically comes back after the QNAP reboots.
PuTTY access
I can connect using PuTTY with:
Host: QNAP-IP
Port: 7001
Connection type: Raw
This gives me the normal interactive OPNsense serial console through PuTTY.
Web console
I also added ttyd to provide a proper browser-based terminal.
This is accessed using:
http://QNAP-IP:7681
I always use IP because OPNSense is my DNS server too...
This works particularly well from Safari on an iPad/iPhone and gives me a proper interactive terminal with the normal on-screen keyboard.
Both methods ultimately connect to the same serial console:
PuTTY -> TCP 7001 -> ser2net -> /dev/ttyACM0 -> DEC750v2
or:
Browser -> ttyd -> netcat -> ser2net -> /dev/ttyACM0 -> DEC750v2
Why I wanted this
My main reason for doing this is safer OPNsense upgrades.
Before upgrading I can create a ZFS snapshot/boot environment.
If an upgrade then breaks OPNsense badly enough that the WebGUI and SSH aren't available, I still have access to the physical serial console.
The particularly useful part is that the serial connection is available throughout a reboot. This means I can see the DEC/FreeBSD boot process and interrupt the boot loader if necessary.
I can therefore reboot the DEC, interrupt the FreeBSD loader and select the previous ZFS boot environment without having to physically connect another machine to the firewall.
Obviously this isn't true out-of-band management because the QNAP is still accessed over my normal LAN. However, my network is a flat LAN and devices retain their IP addresses while the firewall is rebooting or unavailable.
This means I can still access another machine on the LAN by IP and from there access the QNAP console server even if OPNsense itself isn't working.
Security
There are a couple of important security considerations.
TCP 7001 is raw, unencrypted and unauthenticated.
The basic ttyd configuration on TCP 7681 is also HTTP and unauthenticated.
I only expose these on my trusted internal LAN.
I would absolutely not port-forward either of these ports or expose them directly to the Internet.
I also have password protection enabled on the OPNsense console menu itself.
Other hardware
Although I happened to use a QNAP NAS, there's nothing particularly QNAP-specific about the actual solution.
Any always-on machine capable of running Docker and accessing the USB serial device should be able to do essentially the same thing.
For me it's effectively turned an existing NAS sitting next to the firewall into a small dedicated OPNsense console server, with both PuTTY and browser access.
I hope this might help or inspire someone else...
#8
Web Proxy Filtering and Caching / Re: Caddy Reverse Proxy Not Re...
Last post by Monviech (Cedrik) - August 15, 2026, 09:35:18 PMHey, looks like progress.
The Via: 1.1 Caddy header shows that Caddy is now receiving and proxying the request.
However, proxmox.internal still resolves to both 192.168.10.1 and 192.168.10.4. You should find out where the .4 record comes from and remove it, otherwise clients can still connect directly to Proxmox.
The timeout happens because Proxmox responds with:
Location: https://proxmox.internal/
Your Caddy domain is configured as HTTP only, so the browser follows the redirect to HTTPS port 443, where you don't have this domain configured. Proxmox really expects HTTPS, so for this one it makes more sense to configure HTTPS in Caddy with an internal/self-signed certificate or Let's Encrypt.
And yes, browser DoH bypasses Unbound and therefore your local overrides. Setting an external DNS server in System > Settings > General is different; your clients can still use Unbound and resolve your local overrides.
(Partially formatted with chatgpt cause Im tired)
The Via: 1.1 Caddy header shows that Caddy is now receiving and proxying the request.
However, proxmox.internal still resolves to both 192.168.10.1 and 192.168.10.4. You should find out where the .4 record comes from and remove it, otherwise clients can still connect directly to Proxmox.
The timeout happens because Proxmox responds with:
Location: https://proxmox.internal/
Your Caddy domain is configured as HTTP only, so the browser follows the redirect to HTTPS port 443, where you don't have this domain configured. Proxmox really expects HTTPS, so for this one it makes more sense to configure HTTPS in Caddy with an internal/self-signed certificate or Let's Encrypt.
And yes, browser DoH bypasses Unbound and therefore your local overrides. Setting an external DNS server in System > Settings > General is different; your clients can still use Unbound and resolve your local overrides.
(Partially formatted with chatgpt cause Im tired)
#9
26.7 Series / Re: Firewall rules and aliases...
Last post by Burthouse4563 - August 15, 2026, 09:20:44 PMI think I might have an alias issue with policy based routing. have you found a fix to this?
#10
26.7 Series / Re: Migrating for ISC DHCPd to...
Last post by funtowne - August 15, 2026, 08:57:37 PMDNSMASQ + radvd is my go to setup. It's a bit complex, but has the added benefits shown at the bottom of this copied + pasted post from the 26.1 release subforum:
I'll use fd00::/64 as my sample ULA prefix for this example, sub in your prefixes as you see fit
1.) Set a ULA Virtual IP with a /64 on the interface(s) where you want ULA stable addressing (eg: fd00::1/64; fd01::1/64 etc.). Reboot so that the IPs are correctly applied to your interfaces. I ran into an issue where rebooting was the only way to get this to apply correctly.
2.) Set RADVD to "assisted", configure other options as you see fit; set router advertisement prio to "high" in radvd
3.) In DNSMASQ set up a DHCP range for your interface(s) as shown below.
Interface: Your interface for the ULA assignment (eg: where the virtual IP is set).
Start Address: Set the ULA Prefix + Start address of your desired range (ex: fd00::1000)
End Address: Set the ULA Prefix + End address of your desired range (ex: fd00::2000)
Constructor: None
Prefix Length: 64
RA Mode: ra-names
RA Prio: Normal
4.) Reboot your clients to force soliciting new addresses if needed.
Set the rest of the settings for the lease time etc. as needed for your environment. The net result is as follows:
1.) My clients receive only SLAAC GUAs. The prefix assigned by my ISP is in practice not stable, thus DHCPv6 is not a great client option for the GUA. I also prefer radvd for announcements as it also sends a shutdown, deprecate and remove route announcement if a prefix changes. The shutdown, deprecate announcement and remove route options are configurable in the advanced settings of radvd per interface. Note that it is also possible to configure DHCPv6 for both the ULA and GUA. However, given most ISPs GUAs are not stable, I went with the route described in this post.
2.) My clients also receive a SLAAC ULA and, if client is able, a DHCPv6 ULA.
3.) Local name resolution for IPv6 will only return ULAs. A lookup of a local client will return either the SLAAC IP, the DHCPv6 IP, or both.
4.) Set DNS forwarding for your interface's domains in Unbound to "forward first" to your interface's IP port 53053 More info here: https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration for configuring unbound forwarding to DNSMASQ.
Note: Enabling both SLAAC and DHCPv6 addresses for the ULA range covers all bases for clients' quirks to get at least one ULA address registered in DNS. For example, Apple devices prefer a "secure" SLAAC-generated IP which cannot be registered via ra-names, but the DHCPv6 address is registered since that is assigned by DNSMASQ. Some of my containers and other clients etc. are only SLAAC and will probably stay that way, therefore SLAAC addresses are registered in DNS for these clients and able to be resolved.
End result:
No messy unbound restarts. All local DNS is managed by DNSMASQ via an unbound forward; all Internet-facing DNS is handled by unbound. Clients have a stable prefix for local IPv6 addressing and a proper GUA for accessing the public Internet. IPv4 is also covered: static and dynamic leases are both registered in DNSMASQ. All bases are covered!
I'll use fd00::/64 as my sample ULA prefix for this example, sub in your prefixes as you see fit
1.) Set a ULA Virtual IP with a /64 on the interface(s) where you want ULA stable addressing (eg: fd00::1/64; fd01::1/64 etc.). Reboot so that the IPs are correctly applied to your interfaces. I ran into an issue where rebooting was the only way to get this to apply correctly.
2.) Set RADVD to "assisted", configure other options as you see fit; set router advertisement prio to "high" in radvd
3.) In DNSMASQ set up a DHCP range for your interface(s) as shown below.
Interface: Your interface for the ULA assignment (eg: where the virtual IP is set).
Start Address: Set the ULA Prefix + Start address of your desired range (ex: fd00::1000)
End Address: Set the ULA Prefix + End address of your desired range (ex: fd00::2000)
Constructor: None
Prefix Length: 64
RA Mode: ra-names
RA Prio: Normal
4.) Reboot your clients to force soliciting new addresses if needed.
Set the rest of the settings for the lease time etc. as needed for your environment. The net result is as follows:
1.) My clients receive only SLAAC GUAs. The prefix assigned by my ISP is in practice not stable, thus DHCPv6 is not a great client option for the GUA. I also prefer radvd for announcements as it also sends a shutdown, deprecate and remove route announcement if a prefix changes. The shutdown, deprecate announcement and remove route options are configurable in the advanced settings of radvd per interface. Note that it is also possible to configure DHCPv6 for both the ULA and GUA. However, given most ISPs GUAs are not stable, I went with the route described in this post.
2.) My clients also receive a SLAAC ULA and, if client is able, a DHCPv6 ULA.
3.) Local name resolution for IPv6 will only return ULAs. A lookup of a local client will return either the SLAAC IP, the DHCPv6 IP, or both.
4.) Set DNS forwarding for your interface's domains in Unbound to "forward first" to your interface's IP port 53053 More info here: https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration for configuring unbound forwarding to DNSMASQ.
Note: Enabling both SLAAC and DHCPv6 addresses for the ULA range covers all bases for clients' quirks to get at least one ULA address registered in DNS. For example, Apple devices prefer a "secure" SLAAC-generated IP which cannot be registered via ra-names, but the DHCPv6 address is registered since that is assigned by DNSMASQ. Some of my containers and other clients etc. are only SLAAC and will probably stay that way, therefore SLAAC addresses are registered in DNS for these clients and able to be resolved.
End result:
No messy unbound restarts. All local DNS is managed by DNSMASQ via an unbound forward; all Internet-facing DNS is handled by unbound. Clients have a stable prefix for local IPv6 addressing and a proper GUA for accessing the public Internet. IPv4 is also covered: static and dynamic leases are both registered in DNSMASQ. All bases are covered!
