(DMZ) TM Server & Koco Box in verschiedenen Subnetzen

[tamkany]

Hallo zusammen,

wir haben die Koco Box im internen Netz stehen, wie auch die Clients und andere Sub-Systeme.
Der TM Server jedoch steht in einem weiteren Netz. Getrennt sind diese beiden Netze durch eine Firewall.

Grundsätzlich funktioniert auch alles soweit, Kommunikation Client -> Server (RDP, SMB o-ä-) genauso wie umgekehrt.

Jetzt aber der Punkt:
Die KIM- Anwendungen bzw die Einrichtung kommt nicht zustande, obwohl wir zwischendrin sämtliche Kommunikation zwischen den Netzen erlaubt haben und die Firewall damit testweise zur Switch degradiert haben.

Wir sehen lediglich eine Kommunikation im Log der Box, die fehlschlägt. Hierbei handelt es sich um einen Broadcast auf Port 8014, der, da Broadcast, nicht über die Switch drüberkommt.

Weiß jemand, ob dieses Szenario (Box in dem einen Netz, Server in dem anderen) funktionieren kann?

Wir hatten im Vorfeld und auch jetzt bei einem mit TM betrauten Systemhaus angefragt, aber dort leider bisher kein hilfreiches Feedback.

Die letzte Aussage des Technikers war: "Für einen reibungslosen Betrieb des Konnektors und der KIM-Dienste welche auf dem Server konfiguriert sind schlage ich vor den Server mit einer 192.168.x.x Adresse zu betreiben"

[FortiSecond]

Wichtig vorab:
Ist der ferne Konnektor ansonsten erfolgreich angebunden? Also Kartenleser, SMC-B usw.?

Wenn ja:

Zur 192.168.0.0/16: Schwachsinn. KIM von CGM, KV.DOX etc. laufen alle mit einem Konnektor, der in anderen Netzsegment oder sonstwo steht. Zumindest solange der Konnektor das zulässt (evtl. zusätzliche Intranet-Routen im Konnektor setzen, aber das dürfte bereits erledigt sein, wenn der Rest läuft) und kein unsauber eingerichtetes NAT querschießt.

Der Broadcast ist nicht relevant. Ob der bei der automatischen Erkennung von Kartenlesern eine Rolle spielt? Die sind aber auf 4242 zu finden

Der Konnektor kontaktiert das KIM-Clientmodul nicht von selbst.
Die Kommunikation geht vom Clientmodul aus und sollte mit den Ports UDP53, TCP443, TCP389, TCP465, TCP636, TCP995 in Richtung Konnektor auskommen.

Wenn Sie den Switch degradiert haben, dürfte nix mehr klappen - außer die Netzmaske wurde angepasst. Denn er "routet" ja nicht, ist kein Gateway.
Umgekehrt darf das Zielnetz nicht in der Netzmaske liegen, wenn ein Router (mit Firewall/Paketfilter) dazwischen hängt.


Ansatzpunkt also:
1) Zustand, dass RDP, SMB, Konnektorzugriff klappt
2) telnet installieren (Windows-Features), dann z.B. telnet konnektor-ip 389 eingeben, um die Reaktion des LDAP zu prüfen.
3) Wenn OK, dann nochmal melden


Wenn nicht:
Der Konnektor möchte das Fremdnetz legitimiert wissen. In den LAN-Einstellungen müsste dafür eine Intranet-Route angelegt werden.
Beispiel mit Konnektor auf 192.168.1.42 und Server mit IP-Adresse 10.10.10.42, Firewall hat in beiden Netzen die .254 (bzw. bei VPN dazwischen halt beide Firewalls...):
Hier braucht der Konnektor einen Eintrag mit 10.10.10.0/255.255.255.0 (und Gateway 192.168.1.254).
Anschließend weiß er, dass das 10er-Netz OK ist und woher die Pakete kommen müssen bzw. wohin er antwortet.


Mhh.... warum nicht auch das Clientmodul im Konnektornetz und Zugriff vom Clientnetz direkt auf das Clientmodul und von dort auf Konnektor?

[baerdoc]

...
Die Kommunikation geht vom Clientmodul aus und sollte mit den Ports UDP53, TCP443, TCP389, TCP465, TCP636, TCP995 in Richtung Konnektor auskommen.

Nur mal aus Interesse: Was wird denn bei KIM über den UDP-Port gesendet?

[FortiSecond]

...
Die Kommunikation geht vom Clientmodul aus und sollte mit den Ports UDP53, TCP443, TCP389, TCP465, TCP636, TCP995 in Richtung Konnektor auskommen.

Nur mal aus Interesse: Was wird denn bei KIM über den UDP-Port gesendet?

DNS wegen .telematik.

Zwar habe ich nicht in die Spezifikation geschaut, ob das CM direkt den Konnektor befragt oder über das OS geht, aber es deutet viel darauf hin:

Server mit lokalem DNS, der für die .telematik den Konnektor befragt. Server hat Windows-Firewall am Start.
CMD mit einem ping auf mail.tm.kim.telematik gab die passende IP zurück, wobei aber ICMP geblockt war, was durchaus gewollt ist. Firefox konnte auf .telematik-Domains zugreifen.
Das KIM-CM hingegen hat erst dann keinen Fehler bei der Auflösung der mail.tm.kim.telematik gezeigt, nachdem es ausgehend nicht nur TCP machen durfte, sondern auch UDP.
Sieht aus wie: "Ich frage nur den Konnektor, der in der .conf steht!"
Aber wie gesagt: Nicht weiter recherchiert, kann auch andere Gründe haben. Aber schaden wird der 53er sicherlich nicht, weil der Server ja vielleicht auch woanders die .telematik braucht

[DocET]

Gleiches Setup mit TI-Komponenten in separatem Setup und ein verlorenes Pfingsten vor einem Jahr für folgende Erkenntnis:

Der KIM-Einrichtungsassistent erstellt direkt nach Auswahl der SMC-B automatisch eine statische Route zum Konnektor auf dem Server, die (weil sie ins andere Subnetz zeigt) niemals erreicht wird.

Abhilfe schafft: Nach o.g. Schritt NICHT mit der KIM-Einrichtung fortsetzten, sondern genau dann über „CMD route delete“ zuerst diese von TurboMed automatisch erzeugte Route zum Konnektor löschen. Das Routing auf den Konnektor sowie der TI-Netze muss in Ihrem Hardware-Router/Firewall eingestellt sein.

Erst nach diesen Schritten mit dem Einrichtungsassistenten fortfahren, der dann erfolgreich durchläuft.

[lcer]

Hallo,

Wenn der Konnektor in einem separaten Netz steht, muss er in seiner Routingtabelle wissen, wo die anderen Netze sind. Deshalb muss man die Intranetrouten unter LAN/WAN -> Intranterouten mit dem passenden Gateway ergänzen.

Soweit die Theorie. In der Praxis habe ich auf dem Router die Schnittstelle für das Konnektor-LAN mit einem NAT versehen. Dann sieht es für den Konnektor so aus, als käme alles von einer IP aus seinem eigenen Netz und die Konnekor-Firewall beschwert sich nicht.

Das CGM-Koco-Tool kann damit aber nicht umgehen. Da hänge ich zur Not einen Laptop/VM in das Konnektornetz. Für die meisten Sachen braucht man das Tool aber nicht.

Grüße

lcer

[FortiSecond]

Das CGM-Koco-Tool kann damit aber nicht umgehen. [...]

Die übergriffige Routenlöschung und -erstellung auf dem PC während der Registrierung einer KIM-Adresse und
die Problematik mit dem Zertifkatspasswort haben dafür gesorgt, dass ich die Mehrheit der Praxen direkt mit KIM von einem anderen Anbieter ausstatte oder nachträglich umgeswitcht habe. Die drei verbleibenden CGM-KIMs halte ich nur zum Selbstzweck am Leben.
Andere Argumente wärem noch Trafficgrenzen und andere Kleinigkeiten, aber da es keine Preisliste für Mehrverbrauch gibt, gehe ich von Fair-Use aus.

Es bleibt aber zu hoffen, ob das 1.5er-Update, das anrollt, gleichzeitig auch ein Qualitäts-Update ist.
Denn eigentlich mag ich CGM KIM wegen des Bestellprozesses

[bofh]

Das CGM-Koco-Tool kann damit aber nicht umgehen. Da hänge ich zur Not einen Laptop/VM in das Konnektornetz. Für die meisten Sachen braucht man das Tool aber nicht.

Wofür braucht man zwingend das Tool? Ich habe es bisher nie benutzt (da sich damals die Version im TM-Verzeichnis am Konnektor nicht einloggen konnte) und weiß daher nicht, was mir entgangen ist.

[tamkany]

Wichtig vorab:
Ist der ferne Konnektor ansonsten erfolgreich angebunden? Also Kartenleser, SMC-B usw.?

Wenn ja:

Zur 192.168.0.0/16: Schwachsinn. KIM von CGM, KV.DOX etc. laufen alle mit einem Konnektor, der in anderen Netzsegment oder sonstwo steht. Zumindest solange der Konnektor das zulässt (evtl. zusätzliche Intranet-Routen im Konnektor setzen, aber das dürfte bereits erledigt sein, wenn der Rest läuft) und kein unsauber eingerichtetes NAT querschießt.

Der Broadcast ist nicht relevant. Ob der bei der automatischen Erkennung von Kartenlesern eine Rolle spielt? Die sind aber auf 4242 zu finden

Der Konnektor kontaktiert das KIM-Clientmodul nicht von selbst.
Die Kommunikation geht vom Clientmodul aus und sollte mit den Ports UDP53, TCP443, TCP389, TCP465, TCP636, TCP995 in Richtung Konnektor auskommen.

Wenn Sie den Switch degradiert haben, dürfte nix mehr klappen - außer die Netzmaske wurde angepasst. Denn er "routet" ja nicht, ist kein Gateway.
Umgekehrt darf das Zielnetz nicht in der Netzmaske liegen, wenn ein Router (mit Firewall/Paketfilter) dazwischen hängt.


Ansatzpunkt also:
1) Zustand, dass RDP, SMB, Konnektorzugriff klappt
2) telnet installieren (Windows-Features), dann z.B. telnet konnektor-ip 389 eingeben, um die Reaktion des LDAP zu prüfen.
3) Wenn OK, dann nochmal melden


Wenn nicht:
Der Konnektor möchte das Fremdnetz legitimiert wissen. In den LAN-Einstellungen müsste dafür eine Intranet-Route angelegt werden.
Beispiel mit Konnektor auf 192.168.1.42 und Server mit IP-Adresse 10.10.10.42, Firewall hat in beiden Netzen die .254 (bzw. bei VPN dazwischen halt beide Firewalls...):
Hier braucht der Konnektor einen Eintrag mit 10.10.10.0/255.255.255.0 (und Gateway 192.168.1.254).
Anschließend weiß er, dass das 10er-Netz OK ist und woher die Pakete kommen müssen bzw. wohin er antwortet.


Mhh.... warum nicht auch das Clientmodul im Konnektornetz und Zugriff vom Clientnetz direkt auf das Clientmodul und von dort auf Konnektor?

Hallo,

der Konnektor ist angebunden und das Kartenlesegerät funktioniert einwandfrei.

Zu Ihren Ansatzpunkten:
1: Funktioniert
2: Funktioniert nicht, auch nicht aus dem eigenen Netz (Telnet 192.168.1.40 von 192.168.1.10 nicht erfolgreich. Weder auf Port 389, noch auf Port 636)

Die Ständigen Routen wurden gelöscht.

In der Firewall sehen wir keine geblockte Kommunikation.

Von der Box aus konnte FQDN accounts.tm.kim.telematik erreicht werden.

Was haben wir nicht beachtet?

[nmndoc]

Hallo,

sorry wenn ich das o.g nur überflogen habe, evtl werde ich es mir später nochmal im Detail durchlesen, daher vielleicht hier etwas, das Sie schon wissen/versucht haben - wir hatten auch schon mal die Netze nachträglich getrennt und das war eine üble Bastelei - aber nicht wegen uns sondern dem, was CGM und Servicepartner da wieder gepf... hatten. Vielleich hatte ich hier sogar die Details/Stolpersteine gepostet? eigentlich wollte ich das und mir notieren - fürs nächste Mal - "eigentlich" wie gesagt.

Aus der Erinnerung:

1) Auf der Kocobox müssen die neuen/zusätzlichen Netze eingetragen werden und als Gateway jeweils die Firewall
2) Die Firewall muss natürlich alle Netze kennen - ist aber mal so nehmen ich an? Und es müssen natürlich unterschiedliche Netze sein, damit dazwischen geroutet werden kann - dh also 192.168.10.x und 192.168.20.x usw
3) Lesegeräte finden den Konnektor? ggf hier sonst die Konfiguration entspr. anpassen
4) Stolperstein 1: auf den Clients und/oder Server warten statische Routen (cmd > route print) eingetragen - die löschen. Ebenso sind manchmal zusätzl. / weitere IPs auf den Clients eingetragen. Das alles weg. Client/Server haben nur EINE IP und EIN Gateway = Firewal
5) Stolperstein 2: und der war richtig übel - obwohl wir die ganze KIM-Nummer rauf und runter neu gemacht haben, deregistiert etc pp - konnten einfach keine KIM-Nachrichten versendet werden (Test via ... wie auch immer der Punkt in TM heißt - da wo man eben von Hand eine KIM-Nachricht an einen Empfänger senden kann) - da kann man auch gleich prüfen, ob das Adressbuch funktioniert. eAU ging logischer Weise ebenfalls nicht - weil das dann ja über KIM geht.
a) Ich glaube schon in der KIM-Konfiguration gab es irgendwo in einem Fenster relativ unauffällig einen Punkt, wo man Einstellungen wie Port, IP etc ändern konnte. Ging danach aber immer noch nur teilweise. Letztlich war es so, dass "irgendwo" - also grob dort, wo die KIM-Konfigurationsdateien liegen - in einer der Dateien fest die alten IPs eingetragen waren (ich glaube die Config vom KIM-Dienst/Modul) - offenbar ist hier eine nachträgliche Änderung nicht vorgesehen - oder der Programmierer hatte keinen Bock mehr.
Dh Dienste beendet - Datei angepasst - Dienst gestartet - lief.

So in Summe halt mal 1-2 Arbeitstage in dem Projekt versenkt - mangels vernümftiger Dokumentation und Umsetzung.


PS:

Auf der Firewall nachzusehen - nicht nur was geblockt wird - sondern überhaupt welcher Traffic drüber geht hilft schon mal, den Fehler einzugrenzen - wenn bei der FW schon gar nichts ankommt, muss es lokal liegen

[nmndoc]

Nachtrag zu oben:

Die Firewall muss natürlich alles, was die Richtung Bestandsnetze geht + Telematiknetze - an die Koconox routen.

[bjoerneman]

Freu mich hier endlich mal ein paar sinnvolle und hilfreiche hinweise zu diesem Problem gefunden zu haben - großen Dank!

Kurz meine Erfahrung aus 11/23 was wichtig ist in diesem Szenario ist:
1. Route - wie hier schon beschrieben - in Koco-Box eintragen und wirklich darauf achten, dass Subnetzkürzel *.*.*.*/24 sowohl so in der Route (zum anderen Netze) als auch in den LAN-Eisntellung gleich sind) - dann sollte die Kommunikation eigentlich funzen und deutlich weniger Drops (bis keine) im Firwalllog der Koco-Box auftauchen.
2. KIM-Assistent (aus meiner Erfahrung sollte man min. ab Version 1.0.28 nutzen! Insbesondere für TLS und CERT-Fragen ist der Assistent deutlich besser geworden und es gibt nun auch Log-Files die klaren Aufschluss über jeweilige Probleme geben - hier sieht mit ob die config.sds vom Konnektor geladen werden konnte und ob das Certifikat vernünftig geladen werden konnte), letzteres war bei mir mit einem UNC-Pfad ein Problem. Ohne die Log-Dateien hätte ich das Problem nicht herausgefunden.

Sehr sehr schade finde ich, dass CGM die Doku dafür nicht aktualisiert und das Szenario mit zwei Netzen nicht dokumentiert ist … dbzgl. ist die gesamte Doku ein Trauerspiel. Ebenfalls schade finde ich das aktuell der Kim-Assistent nur mit der 1.0.24 downloadbar ist, macht es aus meiner Sicht für den Endnutzer unmöglich auf TLS und Certifikat entspannt umzusteigen.

So, könnte mir noch mehr Luft machen, aber belassen wir es dabei … euch mitstreiten weiterhin gutes gelingen und wenig lebenszeitverschwendung durch eine völlig unprofessionelle Umsetzung und dadurch sinnlos überlastete hotlines mit fehlender Unterstützung.

Also deshalb nochmals danke an euch hier … zu überlegen wäre nur ob man nicht eventuell eine Open-Doku (wie Wiki) für die Koco-Box macht … das würde das Handbuch von 2021 ebenfalls updaten …

[bofh]

für die Koco-Box macht … das würde das Handbuch von 2021 ebenfalls updaten …

Das aktuelle Admin-Handbuch für die Box findet man dort: https://www.kococonnector.com/deu_de/do ... x-med.html