Messages

Does the source IP address / subnet in the rule match the source IP address in the log? Can't tell from the screenshots. Everything else looks okay.

Cheers

Maurice

Make sure auto renewal is enabled globally (Services: Let's Encrypt: Settings) as well as in the certificate settings. Check the cron job (System: Settings: Cron). Default is minutes 0 / hours 0 and * / * / * for the rest, which means it runs daily at midnight. Search the log (System: Log Files: General) for 'AcmeClient'. Should log messages about renewal being required or not.

Cheers

Maurice

Ah, wahrscheinlich das Übliche ;). Outbound-NAT-Regeln fehlen. Default-Einstellung ist 'Automatic outbound NAT', dabei werden nur für die Subnetze der lokalen Interfaces Outbound-NAT-Regeln erstellt (hier wohl 10.10.2.0/24). Von 10.10.0.0/16 weiß das NAT nichts. Du musst daher umstellen auf hybrid oder manuell und selbst Regeln anlegen.

Grüße

Maurice

Extending to a /64 or so, okay. But if you'd have to go all the way to a /40 or so (yes, I've encountered that), probably not a good idea. You might lose access to neighbouring subnets. Which could probably be worked around by route-to $gateway or static routes, but that seems all a bit hackish. I'd only consider this if link-local is not possible for some reason.

Cheers

Maurice

For static IPv6 interfaces, dynamic configuration of the upstream gateway address is not supported. Might be worth a feature request.

When configuring the gateway statically, you should use its link-local address. If your hoster only provides you with the gateway's GUA, you might be able to find out the link-local address by temporarily switching the interface to SLAAC and checking the routing table (or do a packet capture and look for Router Advertisements).

If you really have to use the gateway's GUA and it is not in the WAN subnet, the only workaround that comes to mind is expanding the WAN subnet. "Far Gateway" is indeed not supported for IPv6 gateways.

Cheers

Maurice

The "intermittently unresponsive" issue was introduced for both Router Advertisements (which broke SLAAC) and DHCPv6 when OPNsense switched to FreeBSD 12.1 in 20.7. For Router Advertisements, it was eventually solved by patching radvd. So SLAAC works again in 21.1. But for DHCPv6, no fix is available yet (that includes the 21.7 development version). If you depend on DHCPv6, you'll have to use a separate DHCPv6 server for the time being. Since you have Windows clients and might have a Windows Server: The Microsoft DHCP server works just fine.

Cheers

Maurice

wgVPN is the assigned interface, WireGuard is the interface group:
https://forum.opnsense.org/index.php?topic=22778.0

So yes, this is normal.

Cheers

Maurice

Agreed that better integration of the DHCPv6 and DNS servers would be desirable (it's frequently requested). But speaking from experience with other systems where DNS registration of dynamic DHCPv6 leases works, the results probably wouldn't be what you might expect. Many DHCPv6 clients simply don't send a hostname. And because DHCP is very much optional in IPv6, many devices don't support it all. Not only Android, but also many embedded devices and IoT stuff entirely rely on SLAAC. So unless you are extremely restrictive about what devices are permitted in your networks, DHCPv6-only is rather unrealistic.

At some point many of us probably thought that IPv6 is just IPv4 with longer addresses. Upon realizing that this is not the case and that we'll have to change some old habits, it's probably natural to react with "that's bad because it doesn't work like I'm used to". But most eventually get over it.

Isn't every day you do something new a great day?
No hard feelings and all the best!

Maurice

Zwei WANs reichen. Failover bedeutet, dass die Backup-WANs nur verwendet werden, wenn alle WANs mit höherer Priorität ausfallen. Beim Load Balancer werden immer alle beteiligten WANs verwendet. Das bietet natürlich auch Redundanz, d. h. wenn ein WAN ausfällt wird über die verbliebenen geroutet.

Das kombinierte Szenario aus der Doku wäre z. B.: Zwei DSL-Anschlüsse (beide Tier 1) und eine Mobilfunkverbindung (Tier 2). Im Normalbetrieb findet Load Balancing zwischen den DSL-Anschlüssen statt. Wenn einer ausfällt wird alles über den verbliebenen geroutet. Erst wenn der auch ausfällt erfolgt ein Failover auf die Mobilfunkverbindung.

Grüße

Maurice

Maybe something got lost in translation. There currently is no WiFi 5 / 6 support in FreeBSD at all. It's still in development.

Cheers

Maurice

Having every single IP address in DNS is impossible, especially with modern address assignment methods like SLAAC with privacy extensions. Even when using DHCP you would have to rely on clients to correctly provide their hostname, which many don't.

For everything which actually hosts a service, static DNS records work best. DHCP static mappings are possible, too. But why would you really need(!) a DNS record for e.g. a random phone in a guest network?

Just my 2 Cents.

Maurice

Aber wie verhindere ich jetzt asynchrones Routing? Wenn die Anfrage über IP1 rein kommt, darf sie nicht via IP2 beantwortet werden und umgekehrt.

Genau für solche Fälle ist das 'reply-to' Feature da. Die Firewall merkt sich, über welches Interface eine Verbindung eingeht und sendet die Antwort auch über dieses Interface raus (genauer gesagt: an das Gateway hinter diesem Interface). Die Funktion ist für Regeln auf Interfaces mit zugeordnetem Gateway standardmäßig aktiv, also keine weitere Konfiguration erforderlich.

Grüße

Maurice

For that use case OPNsense might be overkill. I would probably use OPNsense for the server and OpenWrt for the clients. OpenWrt runs on many cheap embedded routers.

OPNsense officially only supports x86_64 which makes 50 € rather unrealistic. ARM builds are still experimental, but if you're up for it you could try a Raspberry Pi.

Cheers

Maurice

In / out is always from the firewall's perspective. In your case, an "out" rule on the LAN interface would mean from OPNsense out to the dockers box. Which is not what you want for PBR. An "in" rule is correct: From the dockers box into OPNsense (and then onwards to the selected gateway).

The information available on this issue is very scarce to find.

While https://docs.opnsense.org/ is not perfect, the firewall direction and PBR basics should be covered there.

Cheers

Maurice

Sounds like your endpoints may have overlapping or identical allowed IPs?

Cheers

Maurice