Messages

Du hattest uns zuwenig über deine Anforderungen verraten, bzw. bist du zwischen verschiedenen Anforderungsprofilen (Bare Metal, Virtualisierung) hin und her geschwenkt. Da ist es natürlich schwierig, passende Empfehlungen zu geben. Und anscheinend gehen dann manche Leute in dieser Ungewissheit auch von den eigenen Vorzügen aus.

Ich hatte schon, ich glaub in meinen ersten Post, erwähnt, dass ich mir eine 2 NIC Hardware vorstellen kann, wenn es zu deinen Anforderungen passt. Das "wenn" eben auch, weil die nicht klar waren.
Und wie vorhin erwähnt, zusammen mit Virtualisierung sind Realtek NICs in meinen Augen auch okay, wenngleich ich die selbst doch meide, soweit möglich. Und dass die lediglich 1 GB/s Durchsatz machen, wird dir ja wohl auch vor dem Kauf bewusst gewesen sein. Dann spricht für mich nichts dagegen.

Grüße

Warum dieses kollektive Abwinken? Wisst ihr, wofür die Hardware nun genau gedacht ist?

Für mich ist das aus dem Thread nicht klar hervorgegangen. Es stand auch eine mögliche Virtualisierung im Raum, weil auch andere Services neben OPNsense betrieben werden sollen. Die Hardware ist dafür jedenfalls performant genug und hat ausreichend RAM. Und wenn sich der Hypervisor (wohl Linux) um die Realtek NICs kümmert, hat OPNsense nichts mit denen zu tun, sondern sieht nur virtiO NICs, die sie ganz toll unterstützt.

Und je nach Einsatzzweck können zwei Hardware NICs auch ausreichend sein. Die übrigen virtualisierten Services werden an virtuelle Netzwerke angebunden. So erreicht kann man auch eine gute Segmentierung des Netzwerks erreichen, ohne außen viele Anschlüsse zu benötigen.

Um die weiteren Details über den Einsatzzweck in Erfahrung zu bringen, müssten wir wohl in einem andern Forum weiter lesen.
Für Interessierte wäre ein Link dahin nett.

No. If you don't need the pppoe0, just select igb2 from the drop-down and save the settings.

Which device is assigned to this interface? A ppp by any chance?

Danke! Der Post mit dem Hinweise ist ja noch taufrisch!
Ich hatte einen älteren Post von Franco gelesen, in dem er auf DNSmasq verweist, wenn man die Option nutzen möchte.

Ich habe CP aktuell eben nur mit Umleitung zum Testen laufen. Aber dass iOS nicht gewillt ist, dieser zu folgen, hat sich dabei schon herausgestellt. Windows 11 und Android 15 akzeptieren es.

Bis die Funktion in der Business Edition verfügbar ist, werde ich wohl nicht warten können. Apple Geräte will man hier halt auch willkommen heißen. Also werde ich an der Migration zu DNSmasq nicht vorbeikommen.
Ist nicht so schlimm. Sind nur 3 Subnetze und eine Handvoll Reservierungen, aber dennoch ärgerlich.

Nein, die beiden Installationen sind an verschiedenen Standorten. Die haben nichts miteinander zu tun.

Die Hostadresse zeigt auf die eigene WAN IP.

No, it's static. It's just the license fee you have to pay for OPNsense. It doesn't grow with hardware scaling.

Ich hatte gemeint, ich betreibe zwar HA und CP, jedoch nicht zusammenhängend. Also auf unterschiedlichen Installationen.

Was meinst du, was ich wo einsetze? Beim Hostnamen?
Da verwende ich einen ebensolchen, also einen Domainnamen, der übers Public DNS auf die WAN IP der OpenSense auflöst.

Dafür habe ich auch ein LE Zertifikat. Könnte also auch https nutzen, wenn nötig. Das ist aber auch erst im Aufbau und bislang noch nicht umfangreich getestet.

Ich traue dem CP auf OPNsense eher als einem auf einem AP, so jedenfalls wenn der AP im LAN hängt. Damit würdest du diesem die Kontrolle überlassen, dass die Gast-Nutzer tatsächlich ausschließlich ins Internet verbinden dürfen, nicht lokal, was wahrscheinlich gewünscht ist. Das habe ich lieber auf der Firewall.

Warum bist du so sehr von dem Gedanken besessen, dass die CARP VIP für CP genutzt werden müsste?
Der Service steht auf beiden Nodes zur Verfügung und kann ebenso gut über die Interface IP genutzt werden.

Die CARP VIP soll es für Services sein, die man auf den Clients fest mit einer IP konfiguriert.
Für CP wird nichts am Client eingerichtet. Der Client versucht einfach eine Verbindung ins Internet aufzubauen. Ja, die geht auf die CARP VIP (als Upstream Gateway) und wird auf OPNsense umgeleitet auf die Interface IP. Der Client sollte damit kein Problem haben, denke ich.

This is used for public key authentication.

Most of us still use pre-shared keys to authenticate the remote site. But public key might be more secure, so the docs recommend to use it.

If you want to do it with public keys, take the public key from A and add it to B.
You can do this also in VPN: IPsec: Key Pairs, but instead of generating one, just insert the public key into the respective field and state a name.

Also install the public key from B on A in the same manner.

In the authentication settings you have to select "public key" for the method and the proper public keys then. On A the A key for local auth and the B key for remote auth. Do it vice versa at B.

OK. Aber das macht natürlich nur Sinn, wenn auch die Voucher im Cluster synchronisiert würden.

Ich nutze CP und HA nur getrennt. Kann daher nicht sagen, ob Vouchers synchronisiert werden. Ich hätte angenommen, dass es so wäre, vorausgesetzt die Synchronisation dafür ist aktiviert.

Ich habe HTTPS für das Captive Portal noch nicht aktiviert. Wenn ich http://<IP-Adresse des HA-Knotens>:9000/ aufrufe, wird auf http://<IP-Adresse des HA-Knotens>:8000/ umgeleitet.

Ja, richtig. Wenn kein Zertifikat eingerichtet ist, bedient 8000 http und 9000 wird dahin umgeleitet. Hatte ich soweit noch nicht untersucht.

Du meinst vermutlich das Captive Portal und nicht CARP Service, oder?

Ja, sorry.

Wenn man die URL des Captive Portal mit http://<CARP-IP-Adresse>:8000/ aufruft, kommt ein Timeout. Wenn man http://<IP-Adresse des HA-Knotens>:8000/ aufruft, dann erscheint das Captive Portal.

Eigentlich sollte nichts davon funktionieren. Der Port 8000 ist für https gedacht. Mit http müsste der Aufruf fehlschlagen.

Wenn das aber ein Schreibfehler ist oder der Browser automatisch unbemerkt auf https gewechselt ist, würde das heißen, die Webseite ist nur an die Interface-Adresse gebunden.

Ich verstehe aber immer noch nicht, weswegen es die CARP IP sein muss. Ebenso gut kannst du die IP der Backup-Node in den URL reinsetzen und die Webseite sollte auch aufgehen.
Wie oben geschrieben, wenn CP synchronisiert wird, sollte auf der Backup die Loginseite ebenso auf der Interface IP bereitstehen.
Also wenn diese Master ist, macht sie eben die Umleitung auf ihre Interface IP. Dem Client sollte das egal sein.

Wenn du es aber dennoch auf der CARP VIP haben möchtest, dann leite die Anfragen eben auf die Interface-Adresse weiter.
Also eine Destination NAT Regel am jeweiligen Interface erstellen mit der CARP VIP als Destination und Port 8000 (f. Zone 0) und als Redirect Target die Interface Adresse (die vordefinierte Variable, damit die Regel auch auf der Backup funktioniert) und Port 8000.
Dies ist für https. Für http wäre noch eine Regel mit Zielport 9000 nötig.

Hallo,

wie du selbst schon recherchiert hast, können Usernamen in Firewall-Regeln nicht verwendet werden. Dabei ist wohl auch zur Sprache gekommen, wie die Regeln funktionieren: mit Interfaces, Netzwerkprotokollen, IPs und Ports

Als Unterscheidung der User bleibt da nur die IP.
Auch wenn du die Umsetzung in OpenVPN über CSO oder eigene Instanzen als wenig elegant empfindest, es ist die gängige Praxis.
Soweit ich weiß, bieten da die VPN-Alternativen auch nichts besseres.

Einen Client Specific Override einzurichten, ist aber doch nicht wirklich ein großes Unterfangen?
Wenn du dann noch einen FW-Alias für die User-IP hinzufügst, kannst du übersichtlich den Usernamen in Regeln verwenden.

Since connections are different and tunnels are unique, wouldn't opnsense be able to route traffic correctly?

So you have two VTI Interface in different networks and with different gateways (remote endpoints). Say
A: 10.0.21.1/24
B: 10.0.22.1/24

Behind both remote site there is a subnet of 192.168.0.0/24.
Hence OPNsense needs these routes:
192.168.0.0/24 > 10.0.21.1/24
192.168.0.0/24 > 10.0.22.1/24

You can verify this by checking the routing table.

I'm pretty in doubt, that you can reach both remote networks with this. NAT (masquerading) will not change anything on this fact. It's just the remote networks, which need to be different to enable routing.
As I sayed, the masquerading must be done on one of the remote sites.

It does say in the doc here : https://docs.opnsense.org/manual/vpnet.html#route-based-vti
that NAT rules can be specified on VTI interfaces in pure VTI-based setups without issue.

Yes, you can. But even if you masquerade the remote subnet on your site it does not change the fact, that multiple (VTI) interfaces are bound to the same or overlapping subnets. And this leads into the problem that OPNsense will not be able to route the traffic to the correct remote site.

Wenn man als Länge für den Benutzernamen "0" eingibt, erscheint folgende Fehlermeldung:

Die folgenden Eingabefehler wurden entdeckt:

• Benutzernamenlänge muss eine Zahl oder leer für den Standardwert sein.

[/list]

Das war ein Vorschlag, es zu versuchen.
Aber wahrscheinlich hatte ich das selbst schon getan und dieselbe Erfahrung gemacht, jedoch vergessen. Die Fehlermeldung brachte mir ein Déjà-vu.

Okay, nicht synchronisiert werden die offenen Vouchers. Also man kann sich mit dem genutzten Voucher bei einem Wechsel auf die Backkup-Box nicht wieder anmelden.

Das Problem mit der Interface IP verstehe ich aber nicht. Das einzige, was in CP angegeben werden kann ist der Hostname, auf den die Webanfragen umgeleitet werden. Dieser kann per DNS an die CARP-IP gebunden sein, kann aber auch an ein anderes Gerät gebunden oder es kann auch die CARP IP selbst sein.
Aber das CARP Service selbst wird ja nicht an eine IP gebunden.
Ich frag mich daher, was da nicht funktioniert.