Messages

Hallo und guten Abend,
habe ein Verständnisproblem bzw. fehlt mir aktuell der richtige ansatz.
Folgendes, verwende 3 IPSec VPN Tunnels für die Außendienststellen (A, B, C) die zu unser Zentrale (Z) sternformig verlaufen. Zukünftig soll der ganze Datentransfer der Außenstellen (A, B, C) über die Zentrale laufen auch was beispielsweise das Internet betrifft. Genügt es an den Außenstellen eine default Route 0.0.0.0 an das VPN GW übergeben?

Wieso:

Die Route ist mit 192.168.1.1/24 und Gateway mit 192.168.178.30 eingerichtet.

Entweder:
192.168.178.0/24 über 192.168.178.1
oder
0.0.0.0/0.0.0.0 über 192.168.178.1


Die FW Regeln müssen natürlich auch passen.
Wenn die Fritzbox als Upstream GW eingetragen sollte das schon passen. Änderungen am GW bedarfen aber einen Neustart oder beim Neustart des Interface.

- Prüfen ob ping von der opnsense zur Fritzbox möglich ist
- Clients haben den GW eingetragen

wir nutzen macOS mit M$ Office 365, das geht gut hauptsache kein Windoof

Naja, macOS ist auch nicht gerade der Burner. Zudem die überteuerte Standardhardware zu Applepreise kaufen... nein Danke.
Pest oder Cholera, dann lieber Windows.

Also wir verwenden in einem anderen Bereich auch WSUS Server. Das funktioniert seit jahren tadellos und sehr stabil. Daher ist Linux keine alternative zu einem gut funktionierendem WSUS System.

Meine Idee war eine Whitelist im Proxy Modul zu nutzen. Allerdings verwende ich den Webproxy bereits für eine andere Schnittstelle. In der grafischen Oberfläche konnte ich keine Möglichkeit entdecken mehrere Konfigurationen für den Webproxy zu hinterlegen.

Hat jemand vielleicht noch eine Idee wie die Windows Update Server, die dummerweise Wildcard URIs verwenden, in OPNsense eintragen kann?

Github -> Sourcecode -> Perfekt!

Vielen Dank... darauf wäre ich nicht gekommen :)

Bei den Admins mache ich mir keine Sorgen. Allerdings möchte ich der Gefahr durch Schadsoftware vorbeugen. Wenn seitens der Firewall nur Zugriff auf "vertrauenswürdige" Microsoft Seiten durchgewunken wird, wäre seitens der Sicherheit vieles gewonnen.

Hallo zusammen,
der WSUS Server muss aber ebenfalls im Internet seine Updates abholen.
Verlagere somit das Problem von Windows 10 auf einen Windows Server.

Warte mal noch ab ob jemand eine Idee hat wie das mit Bordmitteln zu lösen ist. Denke ich werde nicht der einzige sein der vor dem Problem steht/stand.

[Source: Alias/Hostname -> Destination: ANY -> Port: 80, 443]

Hallo zusammen,
nach viel testen komme ich ziemlich gut mit der OPNsense zurecht.
Was mir aber bisher nicht gelungen ist, ist für die Windows 10 Clients das Update über das Internet einzustellen.
Gelungen eigentlich schon, aber es ist nicht richtig gut da das Loch doch etwas groß ist.

Die Vorgabe ist, ein Windows 10 Client darf sich nur zu den Microsoft Update Servern im Internet verbinden. Ansonsten ist jegliche Kommunikation ins Internet verboten.

Der erste Aufbau meiner Regel sieht so auf:

Source: Alias/Hostname   -> Destination: ANY   -> Port: 80, 443

Das funktioniert zwar, aber der Rechner kommt auf jede Internetseite. Idee war nur die Destination mit den Zielservern einzugrenzen.
Bei Microsoft existiert eine Liste mit entsprechenden Server URLs. Allerdings verwenden diese Wildcards. Die OPNsense kann aber mit Wildcards nicht umgehen.


Hat mir jemand einen Tipp wie ich das sinnvoll eingrenzen kann?

Hallo zusammen,
die OPNsense ermöglicht Updates über das Internet zu beziehen. Gibt es eine Serverliste die das Update im Internet abfragt? Aufgrund von Vorgaben muss ich die Firewallregel so präzise wie möglich gestalten. Mit Destination WAN und Port HTTPS reicht leider nicht aus.

Wenn ein Failover oder Load Balancing konfiguriert ist die "doppelte IP" mit hoher Wahrscheinlichkeit eine Virtuelle IP. Schau mal in der Konfiguration nach ob es dort einen Punkt dafür gibt.

Ein Switchport kann genau einen Access/untagged und endlich viele Trunk/Tagged Ports besitzen. Der Switch würde meckern oder das Speichern der Konfiguration verbieten wenn bei einem Port mehrere VLANs als untagged definiert wären.

Warum ein zweites WAN? Steht nirgends und macht doch gar keinen Sinn. Der LAN Port des VPN Routers gehört an ein Interface der OPNSense Firewall.

Ganz ehrlich, was Eure Firma macht oder nicht ist mir ziemlich wurscht. Wenn einer in Eurem RZ Ahnung vom Netzwerkdesign hätte, dann hättet ihr schon längst ein Gespräch gehabt.
Ihr scheint sehr viele Netzwerkbaustellen in der Firma zu haben aber nicht die richtigen Leute die das notwendige Wissen haben um die Anforderungen Professionell umzusetzen.
Wenn alle Stricke reißen holt Euch Rat von einem Systemhaus oder noch besser, lasst es aus einer Hand umsetzen.

Sorry, das klinkt sauhart aber manchmal ist es besser sich Hilfe zu holen als sich komplett zu verzetteln.

Die OPNsense macht genau das was se soll. Es ist eine stateful inspection Firewall und diese muss den Traffic in beide Richtungen kontrollieren! Ansonsten werden die Pakete verworfen. Das ist aber nur für TCP/IP aufgrund des Handshakes gültig.

Bau das Netzwerk einfach richtig auf ohne Krücken, wie es auch JeGr schrieb.


Wenn du diese Krücke weiterbetreiben möchtest muss der Haken bei "Bypass Firewall Rules for traffic on the same interface" gesetzt sein oder du baust dir das selbst mit 2 Firewall Regeln.
Dazu brauchst du eine normale für das IN Interface und eine Floating Regel.
-> wurde bereits negativ getestet.

Mag schon sein dass auf der Unifi über die Profile der Port untagged ist. Die Frage ist nunmal ist der Port untagged im neuen Internet VLAN auf dem der Router des Providers hängt?

Vielleicht schaust du dir das Thema VLANs nochmals genau an. Eine fehlerhafte Konfiguration kann hier schlimme Folgen haben. Mit dem Medienwandler, bzw. einem anderem Gerät, fährst du auf der sicheren Schiene.

Normalerweise sind die VLAN Ports der Firewalls immer getagged. Die Router/Modem des Providers hat wahrscheinlich keine VLANs konfiguriert und läuft standardmäßig im VLAN-1 (default VLAN).

Zum testen auf dem Switch ein VLAN 101 für das Internet als untagged definieren. Dort das Modem/Router des Providers einstecken.
Die OPNsense muss auf dem Switch getagged und softwareseitig entsprechend konfiguriert sein.

Wenn ich mir Dein Netzwerk aber so ansehe, ist es evtl. doch besser den Medienkonverter weiterhin zu betreiben.
Wir verwenden an manchen Stellen ebenfalls die Konverter für SMF und MMF. Bisher noch nie stabilitätsprobleme oder sonstiges gehabt.

Frage, verwendet Ihr Cisco CBS oder Meraki Switche?

Hallo,
ein VLAN auf Layer-2 Ebene routet nicht.

Vermutlich wird Dein Provider Router kein VLAN können. Daher muss der Port, an dem das Gerät hängt, untagged bzw. ein Access-Port sein auf dem Internet VLAN. Die Uplinkports bzw. zur OPNsense sind Tagged bzw. Trunk-Ports.