Messages

Das ist ja wenigstens Traffic, der die OpnSense durchläuft. Kann schon mal passieren, dass Pakete im falschen Zustand ankommen und geblockt werden, z.B. wenn TCP-Verbindungen stale werden.

Yup, as I said, the moment you connect via HTTP/2 to Zoraxy with OpnSense as the backend, it does not work any more.

There must be something that is special on the backend when that happens which OpnSense does not like. However, I have found no way of setting or deleting HTTP headers on the frontend not could I find a setting within Zoraxy to change it. I used many combinations of advanced settings, like deleting headers that pertain to HTTP/2, to no avail.

The only approach I can think of is to dump all request data on the HTTPS backend - but that is not easy, since you cannot easily use tcpdump for that, you will need to have the web server (or Zoraxy as the client) do it. Zoraxy itself is relatively fresh - there is a bug open for this problem and there are no means to log requests, either (that is a feature request).

Das sieht allerdings seltsam aus, weil die beiden IPs mumaßlich im selben Subnetz 10.20.1.0/24 und offenbar auch auf dem selben Interface liegen. Ich nehme außerdem an, dass die Interface-Gruppe local_vlans das vlan20 enthält. Dann ist es allerdings so, dass dieser Traffic die OpnSense nicht passieren dürfte.

Du schriebst allerdings eingangs etwas von /16, das passt ja nicht so ganz.

Only a minor observation, but I could access at least the / URI with curl - IFF I call "curl -vk --http1.1". You cannot try this on any modern browser, since you cannot force HTTP/1.1 any more with TLS/ALPN.

Also, I tried modifying HTTP headers to no avail. There seems to be something way off with the way Zoraxy translates frontend calls to backend.
Other reverse proxies do this just fine, like HAproxy or Caddy.

You do not have to set an upstream DNS server for Unbound at all, because it can resolve on its own.

Try leaving the DNS servers empty in System:Settings:General and uncheck both "DNS server options" on that page.

If both firewalls can ping one another (BTW: on which address? The tunnel IP or their LAN IP?), then it seems obvious that your firewall rules created in step 6 of the official instructions are wrong. You should not have to use NAT on the Wireguard interfaces. Just follow the docs.
 

No, Patrick, just no. That device is not at all transparent, which is a huge difference.

Should I add a new point "About Home Network Guy's and other's youtube videos and why to avoid transparent bridges in general" to the READ ME FIRST article? Up to this point, I avoided changing the order because of the many references, but this one should probably be way up.

Or you go cheap (as I did) and switch to Intel 12th-14th gen. Those LGA1700 boards are still available and many use DDR4. New AM4 boards are unobtanium. And having had the experience of a 400€ board passing out after less than three years, I am not too keen on trying a used/refurbished one.

I never had failing RAM until now, only mainboards. I think it is getting worse with the voltage regulation now on the mainboards instead of the PSU and the obscene power draw of modern CPUs.

Yup, sometimes, this hits earlier than one thinks... Yesterday, I found my Proxmox server getting unstable until I increased Vcore by 100mV - obviously a VRM is on its way out.

Replacing it by a current platform means getting 128 GByte of DDR5 instead of DDR4, which costs ~1500€ for any non-abysmal speed at the time of writing, so the cost for mainboard, CPU, RAM and cooler comes to ~2500€

It is an AM4 system with lots of storage, so I need a decent chipset for many PCIe lanes - X570 is the only one that fits. The only specimens capable of handling my needs and still being available are at least 400€ and are backordered.

At that price, it is easier to keep the existing RAM and order an Intel LGA1700 based board, CPU and cooler for the same cost.

IDK, because "AI" can mean anything, so, probably, yes, it may prevent you from running "anything", too.

BTW: Do you still love your router?

IMHO, using a router on top of another is a bad thing (tm) in the first place. Having one of these routers do unspecified magic "might" make it even harder. Once you throw an unknown variable in the mix (i.e. your first router), you will not get much helpful advice with the other (OpnSense).
Even less so when you use a non-typical setup like a transparent bridge.

The problem is / was probably present before. If you use DNS names for wireguard peers, then the daemon will only resolve them once on start and never recognizes if the peer's IP changes. There is a cron job "Renew DNS for Wireguard on stale connections" which will restart Wireguard. You can run that job every 5 minutes and it will probably fix the DNS resolution problem during startup, too (at least after 5 minutes).

This has been reported over an over, so now I appended it as point 30 here: https://forum.opnsense.org/index.php?topic=42985.0

Firewall aliases are meant to be used with pf rules. pf acts on IPs and subnets. So what should a DNS "domain" mean in that context?

It is not even a specific hostname within a domain, which could at least be resolved to an IP (or a set of IPs).

You can use domains in DNSBL lists to block DNS resolution of specific names, but that is another concept that has nothing to do with firewall rules (and aliases).

Wenn Du individuelle Interface-Regeln brauchst, dann musst Du sie entweder im Interface oder in den Floating Rules machen.

Die Priorität ist ja in der offiziellen Dokumentation erläutert. Floating Regeln sind ganz vorne, dann kommen Interface Gruppen, dann Interfaces.

Entsprechend muss man die Regeln auch positionieren. In den Floating Rules kommt das, was mehr oder weniger für alle gilt - übrigens kann man dort auch Interface Gruppen verwenden.

Wenn Dir das zu unübersichtlich ist, kannst Du auch alle Regeln in den Floating Rules belassen, dann übersiehst Du nichts.

I have to access the WAN net because I'm behind another NAT unfortunately. Should The Admin Aliases to Firewall be placed in the Floating, or are they best left specifically for the Admin VLAN rules?

If they are really VLAN-specific, they do not need to be in the floating rules. As I said, I put everything there that I need to have for many VLANs or things that must override inbound NAT rules. Those with "pass" rules are evaluated before any interface-specific rules, so they must be done in the floating rules. As an example, when you want geoblocking on WAN, you may have to do that in the floating rules, because otherwise, your forwarded ports will not be protected.

IDK, but I doubt it. Did you install the microcode updates?