OpenVPN Firewall-Regeln - welches Interface

[theq86]

Hallo,

ich betreibe 2 OPNsense Instanzen unabhängig voneinander. Einmal zu Hause hinter nem Modem und ein mal bei Hetzner als vServer. Beide haben die aktuellste 18.1 Version.

Auf beiden laufen OpenVPN Server (Zwei daheim, einer beim Hoster - auch hier, völlig unabhängig von einander).
Auf jeder OPNsense sind die Server jeweils einem Interface zugeordnet (unter Schnittstellen)

Jetzt das Verwunderliche:

zu Hause:
Firewallregeln des zugeordneten Interfaces funktionieren, auch wenn in "OpenVPN" keine Regeln sind

Hoster:
Firewallregeln funktionieren NICHT. Ich muss explizit das "OpenVPN" Interface nutzen und wenn ich Traffic im zugeordneten Interface durchlasse, aber bei "OpenVPN" nichts drin habe, ist keine Kommunikation möglich.

Wann wird also was genommen?

[JasMan]

Hey,

nutzt Du tun oder tap Adapter?

Jas

[theq86]

Ich nutze nur den tun Adapter. Immer und auf beiden Firewalls. Würde mich also schon wundern, wenn es an der Art des Adapters läge.

[JasMan]

Bei einem tap Adapter hätte ich das Verhalten verstanden. Denn da hast Du ja keinen eigenen IP Adapter auf dem Du Regel anlegen kannst. Ich vermute (ich habe selbst nur tun Adapter) das man bei einem tap Adapter die Regeln dann auf dem darunterliegenden Adapter anlegen muss.

Ich musste auf meinem physik. WAN Adapter nur die eingehenden Ports für den OpenVPN Dienst selbst freigeben. Die Regeln für die OpenVPN Clients habe ich dann auf dem virtuellem OpenVPN Adapter angelegt.

Welches Interface siehst Du denn auf der Firewall, wenn OpenVPN Client Traffic gedropped wird?

[franco]

Der OpenVPN Regeln sind Inbound, d.h. Traffic der lokal erzeugt wird und zu Hetzner geht ist automatisch "pass". Auf der Hetzner-Seite wird er aber geblockt, wenn keine Regeln drin sind.

Schon mal vom Hetzer-Server probiert auf das Heim-Netzwerk zuzugreifen?


Grüsse
Franco

PS: Generell sind alle Firewall Regeln Inbound, ausser die Floating, da kann man Inbound oder Outbound wählen.

[theq86]

Franco ich glaube wir reden von Verschiedenem ?!?

Also. Sobald ich einen OpenVPN Server eingerichtet habe, erscheint im Bereich Firewall das Interface "OpenVPN".

Jetzt gibt es aber zusätzlich die Möglichkeit im Bereich Interfaces -> Assign ein neues Interface an der ovpns1 Schnittstelle anzulegen.

Folgende Situation:
Auf beiden Sensen ist ovpns1 einem interface assigned.
Auf meiner Home Appliance gelten aber nur die Regeln für das selbst assignte, auf der anderen gelten nur die Regeln von "OpenVPN"

[franco]

Denke nicht. Kommt wie gesagt auf die Richtung an in der die Verbindungen aufgebaut werden...

> Jetzt gibt es aber zusätzlich die Möglichkeit im Bereich Interfaces -> Assign ein neues Interface an der ovpns1 Schnittstelle anzulegen.

Für Server macht das eigentlich weniger Sinn. Klassisch macht man das nur mit den Clients. Also einer ist Server, der andere Client. Aber wenn es funktioniert warum nicht.

> Auf meiner Home Appliance gelten aber nur die Regeln für das selbst assignte

Ja das ist Inbound, aber für den lokalen Traffic und nicht den Remote Traffic.

Wenn du also von zu Hause zu Hetzner verbinden willst brauchst du die Einstellung genau so wie du sie beschreibst. Wenn du von Hetzner nach Hause verbinden willst dann brauchst du die gleiche Konfiguration auch für die umgekehrte Richtung. Ist dieser Rückkanal aber egal ist alles so wie es soll. 


Grüsse
Franco

[JasMan]

Eine generelle Frage: was ist denn der Unterschied zwischen den beiden Interfaces OpenVPN (was automatisch angelegt wird) und ovpns1 (was man zusätzlich assignen kann). Ich habe das bei mir auch schon gesehen, aber nicht assigned.

[franco]

Das automatische OpenVPN interface ist eine Gruppe wo eingehende Policies gesetzt werden können. Die also für Remote-Traffic gelten der vom Tunnel kommt. Ausgehender Verkehr wird generell immer erlaubt, da ihn die andere Seite ja erlauben muss über genau diese Gruppe.

Das zusätzliche Interface ist für die zusätzliche Nutzung von Firewall-Regeln auf lokalen ausgehenden Traffic. Meistens wird es aber nicht benutzt für Regeln, da das Interface eigentlich nur in anderen Interface Regeln als Redirect Gateway verwendet wird.


Grüsse
Franco

[Gauss23]

Ich buddel mal diesen alten Thread hervor.

Ich habe genau dieses Phänomen auf meinen OPNSense Boxen nachstellen können.

Ich wollte die Regeln unter OpenVPN auf einzelne Interfaces verteilen und habe dazu zu Testzwecken einen Roadwarrior Server mit einem eigenen Interface versorgt.
Alle Regeln, die dieses Verbindung betreffen, habe ich dann auf das neue Interface verschoben.

Effekt ist: im Live View sehe ich die Pakete auf dem richtigen Interface eintreffen, es wird dann sogar eine Regel vom neuen Interface angewandt und die Pakete verlassen dann angeblich sogar die Firewall. Ich sehe keinerlei geblockte Pakete. Trotzdem ist keine Kommunikation möglich. Auch nicht direkt zum GUI der Sense.

Sobald ich die Regeln auch nach OpenVPN Clone (ihnen aber einen klar identifizierbaren Namen gebe), sehe ich im Live View, dass diese Regeln zuerst bearbeitet werden (ist auch erwartetes Verhalten). Der Traffic läuft ganz genauso durch und es kommt eine Verbindung zustande. Es gibt keine Block-Regeln unter den OpenVPN-Regeln. Für mich ist das Verhalten nicht nachvollziehbar. Box wurde dazu auch mal neu gestartet, um wirklich saubere Zustände zu haben. Welche Logs/Infos braucht ihr, um festzustellen woran das liegt?

Interessanterweise klappt das Zuweisen von Interfaces bei OpenVPN-Clients hervorragend. Man kann alle Regeln auf das Interface umziehen und die Kommunikation läuft wie erwartet dann über diese Regeln.

[insecure]

Hallo,
ich habe das selbe Phänomen wie "Gauss23" und kann dies nicht ganz nachvollziehen. Gibt es eine Erklärung, warum die Regel nur bei OpenVPN angewendet werden und nicht bei den OVPN1 - OVPN2 Interfaces?
Liebe Grüße,
Marc

[Gauss23]

Hallo,
ich habe das selbe Phänomen wie "Gauss23" und kann dies nicht ganz nachvollziehen. Gibt es eine Erklärung, warum die Regel nur bei OpenVPN angewendet werden und nicht bei den OVPN1 - OVPN2 Interfaces?
Liebe Grüße,
Marc

Die Regeln werden ja interessanterweise beachtet und angewandt. Nur läuft dann trotzdem kein Traffic drüber. Erst wenn die Regeln in der OpenVPN Kategorie eingetragen werden.

[spi39492]

Hallo,
ich habe das selbe Phänomen wie "Gauss23" und kann dies nicht ganz nachvollziehen. Gibt es eine Erklärung, warum die Regel nur bei OpenVPN angewendet werden und nicht bei den OVPN1 - OVPN2 Interfaces?
Liebe Grüße,
Marc

Mich betrifft das gleiche Verhalten. Bei einem Peer-2-Peer-Tunnel werden die Regeln bei dem assigned Interface verwendet, bei einem Remote-Access-Tunnel nicht, da muss ich die Regeln auch beim generellen OpenVPN-Interface anlegen. Komisch.

[Gauss23]

Hallo,
ich habe das selbe Phänomen wie "Gauss23" und kann dies nicht ganz nachvollziehen. Gibt es eine Erklärung, warum die Regel nur bei OpenVPN angewendet werden und nicht bei den OVPN1 - OVPN2 Interfaces?
Liebe Grüße,
Marc

Mich betrifft das gleiche Verhalten. Bei einem Peer-2-Peer-Tunnel werden die Regeln bei dem assigned Interface verwendet, bei einem Remote-Access-Tunnel nicht, da muss ich die Regeln auch beim generellen OpenVPN-Interface anlegen. Komisch.

Du kannst die Regeln auf dem assigned Interface anlegen, musst dann aber bei jeder Regel unter Advanced "Disable reply-to" anklicken. Dann klappt es. Es gab dazu auf Github eine Diskussion:
https://github.com/opnsense/core/issues/4395

Wie ich gerade sehe kannst Du auch das Gateway, was beim Assignen des Interfaces wohl automatisch angelegt wird, löschen.

[JeGr]

Was ich tatsächlich nicht ganz verstehe - ehrlich gesagt. Vielleicht kann Franco oder jemand mit mehr Einsicht das ggf. erklären. Aber bislang war ich der Meinung, dass die reply-to Statements in der PF Syntax hier keine Probleme machen / machen sollte. Das ist ja im Normalfall nur von Relevanz wenn das Paket theoretisch mehrere Möglichkeiten hätte zurückzulaufen, um sicherzustellen, dass es wirklich wieder dahin zurückgeht, wo es herkam.  Insofern sehe ich da eigentlich keinen Grund, warum nach Zuweisung des OVPN Interfaces und dem zusätzlichen reply-to in der Regel die Pakete nicht mehr ordentlich ankommen bzw. die Antworten nicht mehr zugestellt werden.

Wie Ad im Github Thread schon angemerkt hat, wurde das ja von pfSense geerbt und dort funktioniert das lustigerweise bis heute problemlos. Im Gegenteil, es ist sogar an manchen Stellen bisher durchaus wichtig, dass es so läuft, damit auch bei MultiWAN oder mehreren Tunneln zum gleichen Ziel die Pakete wieder so zurücklaufen wie sie angekommen sind um Verwirrung auf der Gegenseite zu vermeiden.

Vielleicht verstehe ich da auch etwas falsch und die Implementierung ist inzwischen so weit auseinander gedriftet, dass man das nicht mehr vergleichen kann, aber rein von PF Logik her aus Sicht des Paketfilters verstehe ich da das Problem nicht ganz