Messages

Maybe there are some hints regarding the reason of the problem in the remote sites log?

Did you specify a uniqe requid in each child?

Also I'd recommend to state "Trap+start" for the start action.

Hallo!

Ich setze zur Zeit die Unifi Lösung den Unifi LTE Router Pro mit einer VF SIM Karte ein.
In der UDM SE ist der natürlich integriert und mann muss nur einen Haken setzen um diesen zu aktivieren.
Wie kann ich dies in der OPNSense am besten umsetzen?
Gibt es hier Lösungen  mit dem Unifi, oder mit z.B. einem GigaCube von VF.

Du konfigurierst einfach ein zusätzliches WAN Interface und eine Gateway Group, die das Umschaltverhalten regelt. In deinem Fall wäre das LTE Gateway als Tier 2 und das primäre als Tier 1 festzulegen.

An das Interface kannst du praktisch alles anschließen,  was eine Internetverbindung herstellt und einen Ethernet Port hat.
Hinter einem Modem kann auch OPNsense selbst die Verbindung via PPPoE herstellen, aber der Unifi LTE Router ist wohl auch ein solcher und bietet ein privates IP Netz am Ausgang.

Dokumentiert ist das in den offiziellen OPNsense Docs. Die helfen auch bei vielen anderen Themen.
Wenn du nach "OPNsense Multi WAN" im Internet od. YT suchst, findest du wohl noch weitere Anleitungen bzw. Video-Tutorials.

Grüße

.0 and .255 are just the boundaries of a /24 subnet, and as well of all smaller subnets and in these ones they are used as network and broadcast addresses in. But there are many wider subnets used out there.

The Digital Ocean network is 64.225.76.0/23. So its network address is 64.225.76.0 and its broadcast is 64.225.77.255. Hence 64.225.77.0 is in the middle of their subnet and can used for any other pupose.

I'm running two CARP-mirrored firewalls, and want to configure an IPSec VPN. Naturally, the virtual WAN address should be used for all traffic

So you have to translate the outbound traffic with NAT rule.

Jeder Versuch in der OPNSense unter Firewall > NAT > Outbound diesen lokalen Rechner über den BPA Telekom zu leiten schlägt fehl.

Da kannst du auch nichts anderes als Source-NAT-Regeln erstellen.
Eine solche braucht es zwar auch am BPA Interface, aber das Routen muss mit einer Firewall-Regel (Policy-Routing) gemacht werden.

Du brauchst also am Interface, an dem der jeweilige lokale Rechner hängt eine Pass-Regel für den entsprechenden Traffic, und da musst du das BPA Gateway eingeben. Diese Regel musst du nach oben schieben, damit sie vor anderen zutrifft.

"Entspechender Traffic" ist desalb unterstrichen, weil "any" für Ziel-IP und -Port möglicherweise nicht das tut, was du möchtest.
Eine solche Regel routet jeglichen zutreffenden Traffic zum gesetzten Gateway, auch welchen, der interne Ziele erreichen sollte, was dann nicht funktioniert. Benötigt der Rechner Zugriff auf interne Resourcen, musst du dafür sorgen, dass diese Regel dafür nicht angewandt wird. Das mache ich mit einem RFC 1918 Alias als invertiertes Ziel, oder du fügst zusätzliche Regeln für internen Traffic oberhalb dieser hinzu.

Hairpining, wie oben empfohlen, ist eine Möglichkeit, die Antworten auf die richtige Route zu bringen

Ich hatte das falsch verstanden das ist gar nicht Hairpining für eingehende Verbindungen.

Das wäre am VPS eine Outbound NAT-Regel am Wireguard Interface für Source = any, Ziel = der Webserver.

Verstehe ich es richtig, dass du mit Client in diesem Fall die OPNSense an meinem Zuhause meinst.

Ja, genau.
Wenn das alles gemacht ist, sollte es eigentlich klappen, aber das

> tcpdump auf Webserver zeigt eingehende und ausgehende Pakete zwischen ClientIP und 10.0.11.125 (LTE-Client)

deutet darauf hin, dass die Regel nicht greift. Jedenfalls nicht, wenn du auf OPNsense am Wireguard Interface die Antwort-Pakete nicht siehst, dafür aber am WAN.

Was mich besonders irritiert ist, dass die Pakete beim Webserver ankommen und auch raus gehen, aber nie beim Client ankommen. Das brachte mich zu dem Gedanken, dass es sich um ein asymetrisches NAT handelt

Damit dürftest du richtig liegen.

da aber über die ForceGW Regel der gesamte Traffic von beiden Netzen zurück zum VPS 10.0.10.1 geroutet wird bin ich überfragt.

Das wirkt sich nur auf ausgehende Verbindungen aus, nicht auf Respones auf eingehende.

Hairpining, wie oben empfohlen, ist eine Möglichkeit, die Antworten auf die richtige Route zu bringen, hat aber den Nachteil, dass dann aus Sicht des Webservers sämtliche Anfragen von 10.0.10.1 kommen. Die wahre Quell-IP bleibt ihm verborgen.
Wenn du diese am Webserver sehen möchtest, braucht es Folgendes:

• Am Client musst du der Wireguard Instanz ein Interface zuweisen und aktivieren, falls noch nicht geschehen.
• Auf diesem muss die Pass-Regel definiert werden, die den eingehenden, weitergeleiteten Traffic vom VPS erlaubt.
• Von "Wireguard" (Interface Gruppe) sämtliche Pass-Regeln entfernen. Solltest du für weitere WG Instanzen Pass-Regeln benötigen, ist es am besten, für diese ebenfalls ein dediziertes Interface einzurichten.
  

Grüße

Derzeit ist ein grundsätzlicher Betrieb mit möglich. Aber nur über den Master!

Naja, nachdem der Master die einzige öffentliche IP belegt hat, kann sie von keiner anderen Maschine genutzt werden.

D.h., die einzige Möglichkeit für den Backup-Node ins Internet zu kommen, wäre der Weg über den Master.
Das kannst du einrichten, indem die die Master LAN-IP als Upstream-Gateway einrichtest. Also eine Gateway-Group konfigurierst, in der das eigentliche Internet-Gateway Tier 1 und der Master Tier 2 ist.
Ist das Internet-Gateway nicht erreichbar, wird der Master genutzt.

In gleicher Weise kannst du den Master konfigurieren, damit er die zweite OPNsense als Gateway nutzt, falls er die Backup-Rolle hat.

Hence, it breaks public key security as the private key will leave the OPNsense machine that way.

There is no need to keep the private key externally. Just delete it after importing.

I don't expect, that the private key works with a wrong certificate.
Strange idea.

I had the same problem, when importing a certificate for an open CSR. I assume, this is a bug in OPNsense.

I got around this by saving private key from the CSR / certificate. Then I deleted the cert and reimported it with both values.
This procedure succeeded several times yet.

Which setting is this in the GUI?

As I wrote:

Edit the rule and change the logical operator to OR.

Rules > autodiscover_contoso_com

Accessing autodiscover.contoso.com.eu results in a 502 error due to an invalid gateway. Is this due to SNI str?

You don't forward this to the backend.

You only forward:
mail.contoso.com.eu/*
autodiscover.contoso.com.eu/autodiscover/*

The latter one as you combinde the two autodiscover ACLs with AND.
Edit the rule and change the logical operator to OR.

So basically the communication should work.

As you wrote, the traffic is blocked, do you see any blocks in the firewall log?
In Firewall: Settings: Advanced under "Logging" check "Default block" and "Private networks" and try to connect to the devicebehind the other firewall.

For further investigation use Interfaces: Diagnostics: Packet Capture to sniff the traffic on the involved interfaces on both firewalls.