Messages

[zwei]

Liebe Experten

Nachdem ich auch im Netz nichts Hilfreiches gefunden habe, erlaube ich mir eine Anfrage hier:

Ich betreibe zuhause eine OPNsense Box als router (box1); ich habe darauf und auf zwei mobilen Geräten WireGuard installiert, um die beiden road warrior über den Tunnel als default route ins ownlan und ins Internet zu bringen. Das funktioniert wie geplant.

Nun möchte ich das eine mobile Gerät, ein Laptop mit W10, alternativ auch als road warrior zu einer anderen OPNsense Box (box2) verbinden können und nach dorthin einen split tunnel aufbauen. Das Zielbild sieht aus wie folgt:



Die beiden Tunnel würden nie gleichzeitig bestehen.

Auf der box2 ist WireGuard analog zu box1 konfiguriert, einfach mit einer anderen Netzwerkadresse und eigenen Schlüsseln für den Tunnel. Auch der neue WireGuard-Tunnel auf dem Laptop ist analog zum bestehenden konfiguriert; ich habe dort also zwei Instanzen mit je einem peer. Schlüssel und IP-Adressen sind pro Tunnel jeweils spezifisch konfiguriert.

Das funktioniert leider nicht, die Verbindung wird angeblich aufgebaut, aber es ist kein Kontakt zu hosts im remotelan möglich. Die Verbindung zur box1 funktioniert dagegen wie immer.
Es gibt nun verschiedene mögliche Ursachen, da die box2 hinter einem Providerrouter sitzt, der gateway und DHCP-Server fürs WAN der box2 ist (aber nicht fürs remotelan, das ist die box2). NAT-Probleme gab es bisher dadurch nicht, ein alter IPSec Tunnel hatte seinerzeit so funktioniert. Der Providerrouter hat auch keine aktive Firewall und forwarded seinen WAN-port 51820 an denselben port der WAN-Schnittstelle der box2 weiter. Dennoch sehe ich im Firewall-Protokoll der box2 keinen Verkehr an der WAN-Schnittstelle. Ich nehme deshalb an, dass die WireGuard-Konfiguration auf dem Laptop nicht richtig ist.

-> Sind zwei WireGuard-Instanzen auf einem Gerät ein Problem? Müsste ich dort stattdessen den Tunnel zur box2 als peer der ersten Instanz erfassen und auf der box2 die Adresse der Wireguard-Instanz ins gleiche Netz wie die Instanz auf der box1 legen, damit auf dem Laptop nur eine Instanz nötig ist, zu welcher dafür dann zwei peers gehören?

Ich danke für jeden input; bei Bedarf kann ich die Tunnel-Konfigurationen des Laptops nachreichen.

Beste Grüsse
stoe

Gut, dass ich gefragt habe.

Vielen Dank, Jens, für die Erhellung. Du hast damit meine Fragen beantwortet.

Da liegt mein persönlicher Hund begraben:

Gefiltert wird - und das ist m.E.n. auch so dokumentiert - nur der initiale Verbindungsaufbau, also das erste Paket einer Verbindung. Alles andere wird als State angelegt und durch Stateful Inspection erlaubt

Ich hab diese Dokumentation so noch nicht gefunden, aber Deine Antwort erklärt mir den relevanten Unterschied zwischen iptables und pf. "stateful" bedeutet demnach in pf, dass der Filter "Antworten auf einen initiierten State selbständig" erkennt, während es in iptables bedeutet, dass ich den Status der Verbindung als Filterkriterium angeben kann/muss.

Ich werd mich nun noch ein bisschen mit dem "keep state" beschäftigen (ist für mich ebenso noch "DarkMagicTM", v.a. wenn "PF simuliert ..."), aber das mindset ist mir nun eigentlich klar.

Besten Dank und Gruss
stö

Hallo Jens

Danke für Deine ausführliche und verständliche Antwort, leuchtet mir alles ein. An die quick rules hab ich gar nicht gedacht...

Nur Dein letzter Absatz verwirrt mich, wohl weil ich pf noch zu wenig kenne bzw. noch in iptables denke. Hab mir jetzt mal das Book of pf gekauft.

In iptables regle ich am WAN folgendes ausdrücklich:

• Lass alle Antworten auf im LAN initiierte Anfragen (-> session hat state established) durch;
• Lass allen traffic durch, der mit einer bestehenden Session in Verbindung steht, z. B.  den Datenkanal bei aktivem FTP (-> state related);
• Lass traffic durch, der zwar nicht im LAN initiiert worden ist (-> state new), für den aber eine ausdrückliche Pass-Regel besteht, z. B.  für ssh (Protokoll und Port müssen stimmen)
• Lass hier am WAN Interface sonst nichts rein.

In OPNsense sind Regeln 1, 2 und 4 wohl per default ebenso gesetzt. Wenn ich im GUI neue Regeln definieren will, habe ich aber kein Feld zur Angabe des Status gefunden. Bin grad unterwegs und kann das von hier nicht prüfen, sorry. Vielleicht täusche ich mich ja ;)

Meine Frage war nun, wie ich z. B.  Regel 1 in OPNsense selber formulieren müsste, wenn sie nicht schon vorhanden wäre.

Danke & Gruss
stö

Vielen Dank. Dasselbe schwebt mir eben auch vor, drum hab ich gefragt.

Deine Antworten helfen mir weiter, dafür merci.

Besten Gruss
stö

Danke nasq, das hilft mir weiter.

Er benötigt die Gruppenmitgliedschaft "admins" - das sorgt auch für eine Verwendbarkeit von sudo, wenn man es einstellt und für eine Zuweisung des Users zur unix-gruppe wheel

Das bedeutet dann auch, dass der non-root user dieselben Berechtigungen wie root hat und ein su gar nicht mehr nötig wäre, oder? Egal, damit komme ich weiter.

Schönen Tag und Gruss
stö

Liebes Forum

Neuling hier; ich bin seit einiger Zeit am Durchforsten des GUI (und des Forums) und bin überwältigt von den Möglichkeiten von OPNsense, vorab also mal Respekt an die Beteiligten!

Nun stellen sich natürlich die üblichen Fragen und auf einige hab ich noch keine Antworten gefunden, sodass ich mir erlaube, sie hier zu stellen:

   
• Das FreeBSD Handbuch sagt zu PF, dass die last matching rule greift. Das OPNsense GUI sagt dagegen das Gegenteil, dass die erste passende Regel greift. Finde ich sinnvoll, aber unerwartet. Ist das eine Anpassung von OPNsense (oder von HardenedBSD) und welche anderen Besonderheiten des PF müssen beachtet werden?
• Eine frisch installierte OPNsense hat gemäss GUI keine aktiven Regeln an der WAN Schnittstelle, per default würde alles geblockt, was nicht explizit erlaubt sei. Diese default Drop-Regel sehe ich nirgends im GUI, ebenso wenig wie Pass-Regeln vom WAN zum LAN für Traffic mit Status established oder related. Die müssten aber da sein, schliesslich kann ich mit einem client der OPNsense im Internet surfen. Es gibt also (sinnvolle) default Regeln, die im GUI nicht sichtbar sind. Kann ich das im GUI ändern oder wo kann ich sie stattdessen sehen?
• Wie ist das Zusammenspiel von CLI und GUI? Welche Schnittstelle übersteuert die andere (vermutlich das CLI die GUI) und sind Änderungen in der führenden Schnittstelle in der übersteuerten dann auch sichtbar?
• Wo kann ich bei der Erstellung von PF-Regeln im GUI den «state» des Traffics angeben, also ob die Verbindung established, related, new oder invalid ist (ja, ich komme von iptables/EdgeOS  ;) )?
  
• Welche Berechtigung muss ich im GUI einem non-root user geben, damit er im CLI su nutzen kann? Wie befürchtet einfach alle oder gibt es eine bestimmte Berechtigung dafür, root werden zu dürfen?
• Und schliesslich: Wo hätte ich die Antworten auf all diese Fragen finden können, ohne Euch beanspruchen zu müssen? Die Doku hat mir schon viel geholfen, aber grade zur Firewall sagt sie nicht allzu viel und fremde Doku zu PF ist wohl mit Vorsicht zu geniessen (vgl. erste Frage).

Besten Dank für jeden input und nochmals chapeau an die Entwickler/Betreiber/Supporter von OPNsense!

Gruss
stö