Messages

Gibt es niemanden der das selbe Problem hat und eine Vermutung hat was genau der Unterschied "Any" und z. B. "Lan net" ist? Ich meine, solange der Computer im gleichen Subnetz ist (dem von LAN = 192.168.200.0/24) sollte "Lan net" doch genau so zutreffen wie "Any". :-\

Guten Abend,

nachdem ich meine LAN-Regeln bearbeitet habe ist mir in der Live-View aufgefallen, dass einige HTTPS-Verbindungen teilweise geblockt werden. Surfen auf HTTPS-Websites funktioniert problemlos. Auf ersten Blick habe ich in den Firewallregeln nichts falsch konfiguriertes gefunden.

• Verbindungen vom LAN-Netzwerk (192.168.200.0/32) sollen überall hin HTTPS machen dürfen. TCP sowie UDP. Unabhängig vom Port.

Mir ist aufgefallen, dass wenn ich die Quelle von "LAN net" auf "Any" umstelle die roten Einträge verschwinden. Es also nicht mehr blockiert wird. Kann jemand erklären wieso das so ist bzw. was die optimalste Konfiguration wäre?

Screenshots anbei. Vielen Dank vorab.

Chris

Hallo zusammen,

ich stehe auf dem Schlauch! Auf meiner Opnsense habe ich seit kurzem drei zusätzliche virtuelle OpenVPN-Clients eingerichtet. Jeder dieser 3 eingerichteten Clients, verbindet sich mit anderen Servern des gleichen VPN-Anbieters. Nun ist mir zum zweiten Mal schon aufgefallen, dass plötzlich NAT auf einem der openvpn-Interface ausfällt. Was gibt es für Möglichkeiten diesem Phenomen auf den Grund zu kommen?

Was ich bereits versucht/überprüft habe:

• Vergleich Gateway-Einstellungen über System -> Gateways -> Single
• Vergleich Interface-Einstellungen über System -> Interfaces -> Assignments
• Vergleich NAT-Einstellungen über Firewall -> NAT -> Outbound
• Überprüft, ob das betroffene Interface eine IP hat (Lobby -> Dashboard -> Interfaces)
• Vergleiche Ausgabe von "pfctl -sn" via Console während dem Problem und nachdem es wieder funktioniert hat

Könnte das vielleicht daran liegen, dass wenn meine vorgeschaltete FritzBox kurzzeitig die Konnektivität verliert (z. B. Zwangstrennung über Nacht) dieser Fehler eventuell auftritt?

Ich weiß nicht ob es bei euch ähnlich ist, aber sobald ein Problem nur sporadisch auftritt und nach einem z. B. Neustart der OpenVPN-Verbindung behoben ist und man den Grund dafür nicht herausfindet werde ich immer schnell nervös ;D. Lässt einen nicht ruhig schlafen.

Grüße
Chris

Kann als gelöst markiert werden. Ich habe festgestellt, dass die von mir genutzte Access Server Lösung von OpenVPN in der Version 1.8.7 offenbar einen Bug hat. Sobald ich in der Web-Konfig eine Option verändere, Speichere, die Option zurückstelle und erneut speichere funktioniert das Routing einwandfrei. Genauer gesagt wird durch diese Aktion die fehlende iptable "-A AS0_IN -s 192.168.178.0/24 -j AS0_U_VPNZIEL_IN" gesetzt.

Nachdem ich den AS auf den neuesten Stand gebracht hatte, konnte ich diesen Fehler nicht mehr beobachten und iptables werden nun korrekt gesetzt. Auch die OPNsense hat bei vorh. Erlaub-Regeln keine Probleme mehr den Traffic durchzulassen.

Hallo zusammen,

seit einem Tag bereits quäle ich mich mit dem Problem, dass sobald ich im OpenVPN Access Server die Access Control auf "Routing" anstelle von "NAT" stelle, die meine OPNsense quer stellt. Als kleines Praxisexperiment ist es mein Ziel ein transparentes Site-to-Site VPN zwischen zwei Standorten herzustellen.

Hauptstandort: 192.168.200.0/24
Remote Standort: 192.168.178.0/24

Ich: 192.168.178.35
VPN-Server: 192.168.200.118
OPNsense: 192.168.200.104
Ziel Webserver: 192.168.200.75

Wenn ich von meinem Rechner am Remote-Standort (..178.35) die am Haupt-Standort gehostete Website auf (..200.75) aufrufen möchte sehe ich, dass mein VPN-Server, ohne dabei die OPNsense zu kontaktieren, meine Anfrage an den Zielhost (..200.75) weiterleitet. Soweit funktioniert die hin-Verbindung.
Für die Rückverbindung bemerkt der Zielhost nun, dass die Anfrage aus einem für ihn unbekannten Subnetz (genauer gesagt von ..178.35) stammt und kontaktiert die OPNsense. Diese besitzt eine konfigurierte Route welche besagt, dass 192.168.178.0/24 über das gateway 192.168.200.118 (VPN-Server) erreichbar ist.
Im Live-Protokoll sehe ich jedoch, dass sämtliche Verbindungen mit Quelle: Web-Server (..200.75) und Ziel: Ich (..178.35) am Remotestandort durch die "Default deny rule"-Regel blockiert wird.

Zwei Regeln (eine bei "fließend" und eine weitere bei "lan") welche * aus Richtung
* in Richtung 192.168.178.0/24 erlaubt (erzwungenes Gateway = der VPN-Server ..200.118) ändern daran nichts. Verschiedene Reihenfolgen (am Anfang, am Ende) habe ich bereits versucht.

Ich stehe auf dem Schlauch und komme nicht weiter. Mit "NAT" funktioniert es einwandfrei, da jeder Server im Hauptstandort nur die IP-Adresse vom lokalen VPN-Server sieht. Hier ist die OPNsense komplett außenvor und alles funktioniert wie es soll. Insofern Routing hier überhaupt möglich/üblich ist möchte ich es jedoch damit betreiben.

Ich freue mich über jedes Feedback. Vielen Dank vorab.


[Nachtrag]
Eine temporäre Lösung besteht darin, dass ich für Verbindungen ins gleiche Subnetz wie der VPN-Server NAT vewendet. Verbindungen in (noch nicht erwähnte) andere Subnets am Haupt-Standort via Routing über die OPNsense. Funktioniert mit entsprechenden Regeln einwandfrei.

Gibt es überhaupt eine Möglichkeit die von mir gewünschte Transparenz innerhalb des selben Subnets zu erreichen oder ist meine Idee schlicht Käse? Im Prinzip soll jedes Netzwerkgerät zu jederzeit die "ware" IP-Adresse sehen welche versucht eine Verbindung herzustellen.