Setup Overview:I have successfully configured the OPNsense WebGUI to be accessible via a reverse proxy using the os-caddy plugin, following the official documentation.
- WebGUI Port: Changed the WebGUI port to 8443 (System ‣ Settings ‣ Administration).
- Caddy Proxy: Caddy serves the WebGUI on port 443, as detailed in the "Reverse Proxy the OPNsense WebGUI" guide.
- Firewall: Port 443 is permitted from WAN to the Caddy reverse proxy.
- Access Control (IPv4): Access to the internal OPNsense domain is restricted to my local network using Caddy's access list with the IPv4 subnet, per the "Restrict access to internal IPs" guide.
- IPv6 Setup: The local network is configured for IPv6 using WAN interface tracking (SLAAC/DHCPv6-PD), meaning my local IPv6 prefix is dynamic.
Problem / Constraint:The OPNsense internal domain resolves to both an IPv4 and an IPv6 address. When a client prefers IPv6, it connects to the WebGUI using the local IPv6 address.
While I can initially add the current local IPv6 subnet to the Caddy access list, this configuration will break the next time my ISP changes the IPv6 prefix on the WAN interface, as the local network's prefix is dynamically tracked from the WAN.
Question:What is the most robust and recommended "OPNsense way" to restrict WebGUI access exclusively to hosts on the local network (LAN) when using Caddy as a reverse proxy, especially considering the dynamic nature of the IPv6 prefix from WAN interface tracking?
I am looking for a solution that avoids manual updates to the Caddy access list whenever the upstream IPv6 prefix changes.
A way to force local clients to use IPv4 is to create a rule in the LAN like at the first spot of the ruleset:
Quick
Reject
IPv6
TCP
Source LAN net
Destination This Firewall
Port 80/443
Now the client tries IPv6, gets ab ICMP response that destination is unavailable and tries IPv4 almost instantly. The trick is action reject.