Messages

Guten Morgen wirehire,
um die Sicherheit geht es mir nicht. Mir geht es um die Flexibilität bei Anpassungen und die Einsparung von Installationsaufwand und Wartungskosten. Wie bereits erwähnt, möchte ich die Einstellungen zentral verwalten und nicht an jedem Client einrichten. Die TI hat bereits eine Routing-Anpassung vorgenommen, beispielsweise von 100.102.0.0/16 auf 100.102.0.0/15. Nun muss ich das bei allen unseren Kunden ändern, aber nicht nur an meiner Firewall, sondern auch noch an allen Endgeräten. Das ist ein extremer Aufwand, den ich mir gerne einsparen möchte.

[in]

Hallo zusammen,
vielen Dank für die Unterstützung. Die Tests sind nun abgeschlossen und tatsächlich hat mir der Vorschlag von Ralf Kirmis geholfen. Zwei Firewall-Regeln haben das Problem gelöst.

Regel 1:
Interface "LAN", Direction "in", Source "LAN net", Destination "100.102.0.0/15", State Type "sloppy state"
Regel 2:
Interface "LAN", Direction "out, Source "LAN net", Destination "100.102.0.0/15", State Type "sloppy state"

Tatsächlich sind beide Regeln notwendig und einzeln nicht zielführend. Die Einstellung "Firewall -> Settings -> Advanced", "Bypass firewall rules for traffic on the same interface" hat für meine Testversuche keinen für mich erkennbaren Unterschied ergeben. Trotzdem vielen Dank auch an dich, Patrick M. Hausen, für den Versuch, mir zu helfen. Ich habe jetzt auch mehrere Aufzeichnungen über Wireshark durchgeführt und erkenne dort auch, dass die TCP-Pakete häufig neu gesendet werden und nach einer gewissen Zeit ein TCP-Reset durchgeführt wird. Als Beispiel wurde zunächst die IP-Adresse 100.102.18.141, danach die IP-Adressen 100.102.18.142, 100.102.18.143, 100.102.18.205, 100.102.18.206 und 100.102.18.207 erfolglos kontaktiert. Danach wird der Vorgang abgebrochen.

Guten Morgen Ralf Kirmis und Patrick M. Hausen,
zum Thema Stateful-Inspektion, kann ich leider aktuell die saubere Methode nicht durchführen. Der Kunde ist nicht in nächster Nähe und im täglichen Betrieb auf die TI‑Verbindung angewiesen. Was ich probieren kann und werde, ist die unsaubere Lösung. (Firewall Regel, Quelle 10.24.1.0/24 ZIEL 100.102.0.0/15, Sloppy Status)

Zusätzlich werde ich die Einstellung "Firewall -> Settings -> Advanced" "Bypass firewall rules for traffic on the same interface" aktivieren. Ich gehe davon aus, dass das dein Vorschlag war

Firewall > Settings > Miscellaneous > Static route filtering

Außerdem werde ich mit Wireshark versuchen, die Pakete zu überprüfen, wobei ich dabei nicht unbedingt der Fachmann bin und mich erst einlesen muss.

tcpdump ist dein Freund.

Vielen Dank für die Vorschläge, ich berichte bei Ergebnissen.

Hi Patrick M. Hausen,
danke für deine Rückmeldung. Ich sehe auf der Kocobox, dass ICMP-Pakete verworfen werden. Dadurch, dass die Kocobox ein VPN zur TI aufbaut, soll auch ein Traceroute darüber nicht möglich sein. Ich habe auf dem LAN der OPNsense bereits verschiedene Regeln versuchsweise erstellt, bei denen das Ziel, das Netz der TI ist. Also beispielsweise 100.102.0.0/15 und dort als Gateway die 10.24.1.190. Dies half mir aber in der Versuchsreihe leider auch nicht weiter.

Nur noch einmal zum Verständnis. Ich habe eine Route in der OPNsense erstellt. Diese funktioniert laut Traceroute auch. Allerdings funktioniert der Service der TI nicht. Sobald ich die Route von Hand am Windows-Client setze, funktioniert auch der Service der TI. Der einzige Unterschied ist, dass die Route nun vom Client direkt auf die Kocobox läuft und nicht mehr als "Umweg" zuerst auf die OPNsense und dann auf die Kocobox.

Könnte es sein, dass die Kocobox Anfragen von mehr als einem "Hop" blockt und direkte Anfragen durchlässt? Mir ist ein solches Verhalten unbekannt und ich wüsste auch nicht, wie ich dieses, beispielsweise in der OPNsense, nachstellen könnte. Könnte ich hier eventuell ein NAT-Problem haben, bei dem sich die Firewall als SOURCE einträgt und deswegen die Rückantworten von der Kocobox ins Leere gehen?

Hi wirehire,
danke für deine Antwort. Ich konnte das Problem bereits lösen, indem ich an allen Arbeitsplätzen die Route eingetragen habe. Sinnig ist das aber in meinen Augen nicht. Wir nutzen ja eine professionelle Firewall, um solche Einstellungen zentral zu steuern. Vielleicht hast du ja noch eine Idee zu meiner Frage im oberen Post?

Liebe Forumnutzer,
wir setzen für unsere Kunden seit einiger Zeit erfolgreich OPNsense mit der DECISO-Hardware ein. Wir haben nun einen Kunden aktuell umgestellt und ich stoße auf ein Problem, das ich mir nicht erklären kann, und hoffe auf euer Schwarmwissen.

Aktuelle Netzwerkstruktur:

      WAN / Internet
            :
            : PPPoE
            :
      .-----+-----.
      |  Gateway  |  (Fritz!Box)
      '-----+-----'
            |
        WAN | 192.168.178.0/24
            |
      .-----+------.
      |  OPNsense  +
      '-----+------'
            |
        LAN | 10.24.1.0/24
            |
      .-----+------.   TI-GATEWAY(Kocobox    .------------.
      | LAN-Switch |------------------------ + TI         |
      '-----+------'   10.24.1.190           '------------'
            |
    ...-----+------... (Clients/Servers)


Die OPNsense Firewall hat die Version 24.7.12

Jetzt zum eigentlichen Problem. Um jetzt verschiedene Dienste der TI nutzen zu können, muss der Datenstrom über das TI-GATEWAY geroutet werden.
Ich habe nun unter "System -> Gateways -> Configuration" ein Gateway erstellt. Interface ist LAN, Gateway 10.24.1.190
Zusätzlich habe ich unter "System -> Routes -> Configuration" entsprechend alle TI notwendigen Routen eingerichtet. Als Beispiel Netzwerk: 100.102.0.0/15, Gateway 10.24.1.190

Wenn ich jetzt einen Traceroute von einer Arbeitsstation aus starte, auf beispielsweise "epa-as-1.prod.epa4all.de", erhalte ich die IP-Adresse "100.102.18.143" und sehe, wie die Pakete zunächst über die Firewall 10.24.1.254 und als zweiten Hop das TI-Gateway "10.24.1.190" angesprochen werden. Soweit, so gut. Alle Dienste bis auf ePA funktionieren reibungslos. Stelle ich jetzt dieselbe Route am Windows-Client ein, funktioniert der Dienst wie gewünscht. Der einzige Unterschied ist, dass die Route nun direkt über die Kocobox läuft und nicht mehr über die Firewall.

Nun zur eigentlichen Frage: Gibt es eine Einstellung, die dieses Problem in der OPNsense auslösen kann, oder könnte die Firewall der Kocobox so eingestellt sein, dass Routing nur über einen Hop zugelassen wird und bei mehreren das Paket blockt? 

PS. Bei weiteren Kunden ist als TI-GATEWAY ein Secunet-Router im Einsatz. Mit diesem Gerät ist mir kein Problem bekannt.