OPNsense Forum
International Forums => German - Deutsch => Topic started by: JonnY90 on February 23, 2018, 11:07:56 am
-
Hallo Zusammen,
habe ein Problem mit der Konfiguration meiner Firewall.
Das Problem stellt sich so dar, dass die SSH Verbindung in ein entferntes VPN Netz von der Default Deny Rule betroffen ist, obwohl ich entsprechende Regeln definiert habe.
Der Verbindungsaufbau funktioniert, aber nach 10-20 Sekunden bricht die Verbindung ab und ich muss die Verbindung neu aufbauen.
Das ganze passiert mit der ALLOW Any Rule, als auch mit einer spezifischen Regel für SSH.
Als VPN Client dient ein Raspberry. Route und eigenes Gateway sind eingerichtet.
Regel für SSH:
Protokoll Quelle Port Ziel Port Gateway
IPv4 TCP LAN Netzwerk * * 22 (SSH) VPNNetz
Regel für VPN:
Protokoll Quelle Port Ziel Port Gateway
IPv4 UDP LAN Netzwerk * * VPN_Port *
Ich weiß gerade nicht, wo der Fehler liegen könnte. Vorallem weil der Verbindungsaufbau funktioniert und auch im FW Log entsprechende Einträge vorhanden sind, die die Verbindung erlauben, aber nach ein paar Sekunden greift die Default Deny Rule.
Hoffe mein Problem ist verständlich geworden, ansonsten werde ich versuchen das Problem genauer darzustellen.
Viele Grüße
-
Hallo,
poste doch mal die Details des Log-Eintrags der Firewall wenn der DENY ausgeführt wird.
-
Danke gmu für deine Antwort.
Ich bin auf dem Gebiet leider noch nicht sehr erfahren, habe mit opnsense meinen TomatoUSB Router abgelöst und da musste/konnte ich keine fortgeschrittene Konfiguration vornehmen.
Ich habe mir die Logs nochmal genau angeschaut. Mir war bis dahin nicht ganz klar, dass die FW in zwei Richtungen entscheidet (IN/OUT).
Der Verbindungsaufbau (OUT) funktioniert, aber die Daten die zurückkommen werden blockiert (IN) und von der Default Deny Rule blockiert.
Das heißt alle Regeln (DNS/HTTP(S) etc.) die ich auf dem LAN Interface erstellt habe sind nur Regeln, die den Traffic nach draußen betreffen.
Jetzt habe ich gelesen, dass ich mittels Floating Rules Regeln für den eingehenden Traffic bestimmen kann.
Ist das richtig? Oder gibt es eine andere Möglichkeit?
-
Hallo,
du legst normalerweise für beide Netze (LAN und IPSec) eine Firewallregel an.
Siehe meine Anhänge.
Hier wird in beiden Richtungen alles Erlaubt.
Wenn Du das einschränken willst musst Du die entsprechenden Ports angeben.
-
Danke für deine Antwort, aber so wirklich weiter komme ich damit nicht.
Ich habe ja nur 2 Interfaces (LAN und WAN)
Auf dem LAN Interface habe ich eine Regel die alles in das VPN Netz erlaubt.
Auf welchem Interface muss ich denn die Regel für den eingehenden Traffic definieren?
-
Achso. Jetzt glaube ich hab ich es verstanden.
Der Raspberry baut den VPN-Tunnel.
(PC)---(LAN/OPNsense)--(Raspberry)====(VPN Gegenseite)---(SSH Server)
Ist der Raspberry an LAN oder WAN an der OPNsense angeschlossen?
Ggf. kannst Du ja mal eine Skizze mit IP-Adressen machen.
-
Default deny heisst oft State Tracking Probleme im TCP, asymmetrischer Traffic, etc. Das State Tracking kann man unter den Advanced Settings einer Regel auf sloppy oder none setzen, also auf der Regel auf der der Traffic eigentlich sein sollte.
Grüsse
Franco
-
Habe mal kurz mit Visio was gezeichnet. Bitte seht von falsch verwendeten Symbolen etc ab. ;D
Ich hoffe die Struktur ist zu erkennen.
Der VPN Client hängt am LAN Netz der opnsense Box.
Wenn sich jetzt der PC (192.168.22.2) per SSH zu dem VPN Server (192.168.1.2) bzw. generell zu allem, was sich in dem 192.168.1.0/24 Netz befindet, verbindet, erhält dieser einen Disconnect.
Die Routen sind erstellt und auch das Gateway für den VPN Client wurde eingerichtet.
Wie gesagt ich versteh gerade nicht, wo ich eine Regel für den Traffic definieren kann, den ich nach einem Request erhalte.
Ich dachte eigentlich, dass sich die Firewall den Request merkt und ich über den gemerkten Request, die Daten zurückerhalte.
Edit:
@Franco
also wenn ich den Status Tracking auf "Sloppy Status" setze, erhalte ich keine Disconnects mehr :D Aber so ganz warm werde ich mit dieser Einstellung aber nicht. Woran liegt das denn genau? Bei anderen Regeln z.B. Spotify oder DNS muss ich diese Option ja nicht setzen.
-
Hi JonnY90,
Das kommt stark auf das Netz an, und/oder Komponenten die den TCP Stream negativ verändern. Bei asymmetrischem Traffic fehlt z.B. eine Seite der Verbindung, dann schlägt das Tracking fehl weil eine Seite einen "direkten" Weg zum Ziel nimmt. Manchmal passiert das auch bei starken / out-of-order Retransmissions.
Für Streaming (UDP) oder kurzlebige Verbindungen (z.B. Browsing pro Verbindung nur 1-2 Sekunden) trifft das nicht zu, abgesehen vom komplett asymmetrischen Traffic der hier ja nicht vorliegt weil die SSH Verbindung später abbricht.
Grüsse
Franco
-
Danke für deine Antwort!
Was ich aber noch etwas komisch finde, ist, dass das Problem erst seit Version 18.x habe.
Unter 17.7 hatte ich das Problem noch nicht.
Also an sich klappt es jetzt, ich erhalte keine Disconnects mehr, aber im FW Log tauchen zum Teil immer noch Pakete auf, die geblockt werden.
Wenn ich später wieder Zuhause bin, dann mache ich davon nochmal ein Screenshot.
Danke soweit!
-
Da sich das Betriebssystem von FreeBSD 11.0 auf 11.1 verändert hat ist nicht auszuschliessen, dass sich das Netzwerk geringfügig anders verhält. Nicht immer ist dies durchweg positiv, aber meistens lassen sich Einstellungen finden die das Verhalten dann wieder normalisiert getreu dem Motto "nichts bleibt wie es war". :)
Grüsse
Franco
-
Alles klar Danke!
Dann ist zumindest die erste Baustelle schon mal erledigt! ;D