Telematik Infrastruktur - Anbindung Kocobox/TI-Gateway

[m.hartmann]

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.

[wirehire]

Du musst nur den clients die kocobox routen mitgeben. die clients gehen nicht erst zur sense und dann zur box, sondern generell erst zur box und dann zur ti , wenn du die ti box so installiert hast.

Öffne dein pvs system und lass dir dann die routen anzeigen. da wirst du sehen, dass alles direkt zur ti vpn box geht. warum sollte es auch erst zur sense und dann zur box, sind ja im gleichen subnet .

[m.hartmann]

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?

[Patrick M. Hausen]

Eigentlich denkst du richtig und das sollte so funktionieren. Clients sollten nur einen Default-Gateway benötigen.

Geht es von diesem weiter über einen anderen Gateway im selben Netz, schickt er dem Client ein ICMP Redirect Paket, das Desktop Systeme in der Regel auch beachten. Für einen gewissen Zeitraum (Route Cache) gehen weitere Pakete dann automatisch direkt an den richtigen GW.

Hast du auf dem LAN der OPNsense evtl. Firewall-Regeln, die explizit den WAN Gateway setzen und bei dem ePA Kram greifen? Oder Regeln, die RFC 1918 blocken? Oder irgendwas in der Art? Erlaubt sein muss der Verkehr auf der OPNsense natürlich schon.

[m.hartmann]

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?

[Patrick M. Hausen]

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?

Das eher als alles andere - die Box hat mit "normalem IP" gar keine Möglichkeit, festzustellen, dass da noch ein Router ist. Da müsste man also schon gezielt Zeug einbauen, um das zu erzwingen.

Wie gesagt, ich vermute, die Sense tut irgendwas mit den Paketen, was sie nicht sollte, statt sie einfach nur weiterzurouten. tcpdump ist dein Freund.

[Ralf Kirmis]

Moin,

Stichwort asyncrones Routing.
Das Gateway sieht das erste Datenpaket und schickt es zum TI Router und der zum Ziel.
Antwort vom Ziel kommt über den TI Router und geht dann direkt ins LAN, ohne das die OPNSense das Datenpaket sieht.
Somit ist die Stateful Inspektion auf der OPNSense gestört und das dritte Datenpaket zum Ziel wird nicht mehr zum TI Router geschickt, sondern geblockt.

Die saubere Lösung ist ein eigenes Interface an der OPNSense, an dem der TI Router hängt mit einem Transfer Netz.
Somit gehen alle Daten Pakete über die OPNSense, Stateful Inspektion passt dann.

Die unsaubere Lösung ist eine Firewall Regel auf der OPNSense mit der Quelle LAN und Ziel die TI Routen und dem Sloppy Status.
Ist aber unschön, die Stateful Inspektion so auszuschalten.


LG,
Ralf

[Patrick M. Hausen]

Asymmetrisch, aber ja - hast recht.

Es gibt eine globale Option bei Verkehr über ein- und dasselbe Interface alles zu erlauben.

Firewall > Settings > Miscellaneous > Static route filtering

[m.hartmann]

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.

[m.hartmann]

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.

[wirehire]

Das Problem ist aus meiner sicht, warum willst du es über die firewall ziehen? Oft setzen  die pvs und plugins die routen selber, sodass ,da keine mehr "sicherheit" entsteht. Da wäre der Vorschlag mit, ti box anderes vlan / netz und dann wirklich per fw regeln , wer zur ti box kommunizieren kann, sinnvoller, wenn es dir um sicherheit an sich geht.

Sonst kannst du dir nie sicher sein, welches gerät nicht doch direkt mit der box spricht.

[m.hartmann]

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.

[Patrick M. Hausen]

Am einfachsten ist es tatsächlich, Router zu anderen Netzen nicht ins LAN sondern in ein eigenes dediziertes Netz zu hängen. Dann geht alles sauber durch die OPNsense durch, kein asymmetrisches Routing, alles schick.

[Maurice]

Als pragmatischen Kompromiss zwischen "TI-Gateway in eigenes Netz" und "asymmetrisches Routing" könntest Du auch das TI-Gateway dazu zwingen, alles über OPNsense zu routen, indem Du dort die Präfixlänge anpasst.

Du sagst, OPNsense hat die 10.24.1.254/24. Du könntest das TI-Gateway mit 10.24.1.253/30 konfigurieren. Dann muss es 10.24.1.0/24 über OPNsense routen. Du müsstest dann nur sicherstellen, dass kein Gerät die 10.24.1.252 verwendet bzw. dieses Gerät das TI-Gateway nicht nutzt.

Allerdings hast Du dann umgekehrt asymmetrisches Routing, wenn Du aus dem LAN direkt auf das TI-Gateway zugreifen musst. Wie oft das vorkommt kann ich nicht beurteilen. Falls das eine ferngewartete Blackbox ist dürfte das nicht wirklich relevant sein.

Die sauberste Lösung ist wie Patrick schon sagt ein separates Netz.

Grüße
Maurice