61
VPN-Problem zwischen zwei Standorten
Hallo. Ich habe folgendes Problem:
Ein Standort A ist via VPN an Standort B angebunden.
Standort A hat einen Server, der ein Medizinprogramm ausführt, welches eine Verbindung in das KV-Netz aufbaut.
Das KV-Netz wird über einen speziellen Konnektor an Standort B zugänglich gemacht.
Am Server an Standort A sind entsprechende Routen-Einträge ins KV-Netz über den Konnektor an Standort B hinterlegt.
Das Einholen einer Information funktioniert auch auf diesem Weg. Nur das Versenden von Nachrichten über SMTP will nicht so recht.
Beide Standorte verwenden eine Sophos XG Firewall als VPN Endpunkte.
An beiden Standorten wird alles innerhalb der VPN in beide Richtungen zugelassen.
Zusätzlich gibt es eine Regel am Standort B, die explizit Port 465 TCP (SMTP) von Netz Sandort A nach KV Netz zulässt. Verknüpft mit einer SNAT Regel, die die Quelle als MASQ umschreibt.
Nochmal als Schaubild:
A—(VPN)—B—Konnektor—KVnetz
Wo kann hier das Problem sein, dass keine Nachrichten von Server an Standort A ins KV-Netz geschickt werden können?
Lokal am Server wurde die Firewall bereits testweise ausgeschalten. Ohne Erfolg.
Vielen Dank für alle Hilfe.
Ein Standort A ist via VPN an Standort B angebunden.
Standort A hat einen Server, der ein Medizinprogramm ausführt, welches eine Verbindung in das KV-Netz aufbaut.
Das KV-Netz wird über einen speziellen Konnektor an Standort B zugänglich gemacht.
Am Server an Standort A sind entsprechende Routen-Einträge ins KV-Netz über den Konnektor an Standort B hinterlegt.
Das Einholen einer Information funktioniert auch auf diesem Weg. Nur das Versenden von Nachrichten über SMTP will nicht so recht.
Beide Standorte verwenden eine Sophos XG Firewall als VPN Endpunkte.
An beiden Standorten wird alles innerhalb der VPN in beide Richtungen zugelassen.
Zusätzlich gibt es eine Regel am Standort B, die explizit Port 465 TCP (SMTP) von Netz Sandort A nach KV Netz zulässt. Verknüpft mit einer SNAT Regel, die die Quelle als MASQ umschreibt.
Nochmal als Schaubild:
A—(VPN)—B—Konnektor—KVnetz
Wo kann hier das Problem sein, dass keine Nachrichten von Server an Standort A ins KV-Netz geschickt werden können?
Lokal am Server wurde die Firewall bereits testweise ausgeschalten. Ohne Erfolg.
Vielen Dank für alle Hilfe.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2897703651
Url: https://administrator.de/contentid/2897703651
Ausgedruckt am: 25.11.2024 um 09:11 Uhr
61 Kommentare
Neuester Kommentar
Hallo,
wenn Hänsel und Gretel in den Wald laufen, legen sie immer eine Spur aus Brotkrümeln, so dass sie zurückfinden.
Kurzum: Weiß der Konnektor denn auch, welches Gateway im Netz B er nutzen muss um Netz A zu erreichen?
Gruß,
Jörg
wenn Hänsel und Gretel in den Wald laufen, legen sie immer eine Spur aus Brotkrümeln, so dass sie zurückfinden.
Kurzum: Weiß der Konnektor denn auch, welches Gateway im Netz B er nutzen muss um Netz A zu erreichen?
Gruß,
Jörg
Vielen Dank für deine Antwort. Ja. Die Route ist ebenfalls da.
Moin Joh,
Der Medizinserver ist dann wohl der SMTP Client, korrekt?
Das hört sich leicht nach einer öffentlichen Behörde an, ich tippe mal auf Kommunalverwaltung. 🙃
Was meinst du damit genau?
👍👍👍 😁
Willst du die Mail an ein Ziel innerhalb des KVN's verschicken oder über das LRZ nach aussen?
Läuft die XG SMTP technisch am Standort B als MTA oder im Legacy-Modus?
Leider an vielen Ecken und ohne die Antworten auf die oberen Fragen sehe ich momentan noch kein Licht im Dunkeln.
Wir werden aber schon noch eins finden. 🤪
Mit der FW hat das Ganze primär wahrscheinlich nicht viel zu tun, eher mit dem Routing.
Beste Grüsse aus BaWü
Alex
Ein Standort A ist via VPN an Standort B angebunden.
Standort A hat einen Server, der ein Medizinprogramm ausführt, welches eine Verbindung in das KV-Netz aufbaut.
Der Medizinserver ist dann wohl der SMTP Client, korrekt?
Das KV-Netz wird über einen speziellen Konnektor an Standort B zugänglich gemacht.
Am Server an Standort A sind entsprechende Routen-Einträge ins KV-Netz über den Konnektor an Standort B hinterlegt.
Am Server an Standort A sind entsprechende Routen-Einträge ins KV-Netz über den Konnektor an Standort B hinterlegt.
Das hört sich leicht nach einer öffentlichen Behörde an, ich tippe mal auf Kommunalverwaltung. 🙃
Das Einholen einer Information funktioniert auch auf diesem Weg.
Was meinst du damit genau?
Beide Standorte verwenden eine Sophos XG Firewall als VPN Endpunkte.
👍👍👍 😁
An beiden Standorten wird alles innerhalb der VPN in beide Richtungen zugelassen.
Zusätzlich gibt es eine Regel am Standort B, die explizit Port 465 TCP (SMTP) von Netz Sandort A nach KV Netz zulässt. Verknüpft mit einer SNAT Regel, die die Quelle als MASQ umschreibt.
Nochmal als Schaubild:
A—(VPN)—B—Konnektor—KVnetz
Zusätzlich gibt es eine Regel am Standort B, die explizit Port 465 TCP (SMTP) von Netz Sandort A nach KV Netz zulässt. Verknüpft mit einer SNAT Regel, die die Quelle als MASQ umschreibt.
Nochmal als Schaubild:
A—(VPN)—B—Konnektor—KVnetz
Willst du die Mail an ein Ziel innerhalb des KVN's verschicken oder über das LRZ nach aussen?
Läuft die XG SMTP technisch am Standort B als MTA oder im Legacy-Modus?
Wo kann hier das Problem sein, dass keine Nachrichten von Server an Standort A ins KV-Netz geschickt werden können?
Leider an vielen Ecken und ohne die Antworten auf die oberen Fragen sehe ich momentan noch kein Licht im Dunkeln.
Wir werden aber schon noch eins finden. 🤪
Lokal am Server wurde die Firewall bereits testweise ausgeschalten. Ohne Erfolg.
Mit der FW hat das Ganze primär wahrscheinlich nicht viel zu tun, eher mit dem Routing.
Beste Grüsse aus BaWü
Alex
Moin,
nenn' doch mal Roß und Reiter:
- welches Medizinprogramm (PVS)?
- welcher Konnektor (physischer Konnektor [KoCoBox, SecuNet] oder Cloud)?
- Geht es um KIM? Wenn ja: ist das im Konnektor korrekt freigeschaltet und wo läuft das KIM Clientmodul?
- Wo steht der eGK Kartenterminal und welche Karten sind dort eingesteckt (SMC-B, HBA)?
- Hast Du Zugriff auf den Konnektor und ist dieser auf aktuellem Stand?
- Hat der Kartenleser aktuellen Firmwarestand?
Gruß
cykes
nenn' doch mal Roß und Reiter:
- welches Medizinprogramm (PVS)?
- welcher Konnektor (physischer Konnektor [KoCoBox, SecuNet] oder Cloud)?
- Geht es um KIM? Wenn ja: ist das im Konnektor korrekt freigeschaltet und wo läuft das KIM Clientmodul?
- Wo steht der eGK Kartenterminal und welche Karten sind dort eingesteckt (SMC-B, HBA)?
- Hast Du Zugriff auf den Konnektor und ist dieser auf aktuellem Stand?
- Hat der Kartenleser aktuellen Firmwarestand?
Gruß
cykes
Moin cykes,
das riecht für mich nach Tipps für den Gesundheitssektor.
Du bist hier glaub ich auf der falschen Baustelle gelandet. 🙃
KV-Netz (KVN) steht normalerweise für Kommunales Verwaltungsnetz.
Die kommunalen IT-Baustellen sind übrigens mindestens genau so schlimm wie die des Gesundheitssektors.
Beste Grüsse aus BaWü
Alex
nenn' doch mal Roß und Reiter:
- welches Medizinprogramm (PVS)?
- welcher Konnektor (physischer Konnektor [KoCoBox, SecuNet] oder Cloud)?
- Geht es um KIM? Wenn ja: ist das im Konnektor korrekt freigeschaltet und wo läuft das KIM Clientmodul?
- Wo steht der eGK Kartenterminal und welche Karten sind dort eingesteckt (SMC-B, HBA)?
- Hast Du Zugriff auf den Konnektor und ist dieser auf aktuellem Stand?
- Hat der Kartenleser aktuellen Firmwarestand?
- welches Medizinprogramm (PVS)?
- welcher Konnektor (physischer Konnektor [KoCoBox, SecuNet] oder Cloud)?
- Geht es um KIM? Wenn ja: ist das im Konnektor korrekt freigeschaltet und wo läuft das KIM Clientmodul?
- Wo steht der eGK Kartenterminal und welche Karten sind dort eingesteckt (SMC-B, HBA)?
- Hast Du Zugriff auf den Konnektor und ist dieser auf aktuellem Stand?
- Hat der Kartenleser aktuellen Firmwarestand?
das riecht für mich nach Tipps für den Gesundheitssektor.
Du bist hier glaub ich auf der falschen Baustelle gelandet. 🙃
KV-Netz (KVN) steht normalerweise für Kommunales Verwaltungsnetz.
Die kommunalen IT-Baustellen sind übrigens mindestens genau so schlimm wie die des Gesundheitssektors.
Beste Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Moin cykes,
das riecht für mich nach Tipps für den Gesundheitssektor.
Du bist hier glaub ich auf der falschen Baustelle gelandet. 🙃
KV-Netz (KVN) steht normalerweise für Kommunales Verwaltungsnetz.
Naja, vielleicht bist Du aber auch auf dem falschen Dampfer und er meint das KV-Safenet, die Erwähnung von "Medizinprogramm", "Konnektor" und "SMTP" ließen mich eher auf KIM-Installation tippen. Aber warten wir mal ab. 😁Moin cykes,
das riecht für mich nach Tipps für den Gesundheitssektor.
Du bist hier glaub ich auf der falschen Baustelle gelandet. 🙃
KV-Netz (KVN) steht normalerweise für Kommunales Verwaltungsnetz.
Die kommunalen IT-Baustellen sind übrigens mindestens genau so schlimm wie die des Gesundheitssektors.
Das sehe ich ähnlich ... und bei Anwälten (beA) oder Notaren (beN) und und und ... alle zwangsdigitalisiert mit nahezu funktionsuntüchtigen Systemen, die containerweise im Wesentlichen Geld verbrannt haben.Gruß
cykes
2
Beide Standorte verwenden eine Sophos XG Firewall als VPN Endpunkte.
Ist nicht relevant!Relevant wäre welches der zahllosen VPN Protokolle die Sophos nutzt für die VPN Kopplung, denn ein korrektes Routing der IP Netze ist ganz erheblich davon abhängig WELCHES der zahllosen VPN Protokolle verwendet wurde. Leider dazu keinerlei Auskunft so das kristallkugeln angesagt ist...
Raten wir also einmal etwas im freien Fall....
Vermutlich wurde IPsec verwendet als VPN Protokoll?! Wenn das der Fall ist, dann ist, wie immer, das Setup der Phase 2 SAs hier wichtig.
In der Phase 2 müssen sowohl die IP Netze des jeweiligen remoten Standortes und der KV Zielnetze eingetragen werden.
Die P2 SAs bestimmen bei IPsec VPNs welche IP Netze in den VPN Tunnel geroutet werden und welche nicht, sprich entscheiden also über das Routing.
Ein simpler Traceroute oder Pathping hätte hier übrigens auch sofort Klarheit gebracht...aber egal.
Andere VPN Protokolle benutzen gänzlich andere Routing Mechanismen. Ein Konfig Auszug oder ein Setup Screenshot der FWs würde hier also allen helfen beim Troubleshooting!
die explizit Port 465 TCP (SMTP) von Netz Sandort A nach KV Netz zulässt
Das reicht vermutlich nicht, es sei denn man weiss ganz sicher das explizit rein nur TCP 465 beim Mail Versand verwendet wird.Es fehlen de facto die Ports TCP 25 und TCP 587 die häufig auch verwendetet werden. Man tut also immer gut daran diese Ports ebenfalls zu erlauben.
Moin Aqui,
diese Info ist sehr wohl wichtig, den je nach VPN-Gateway, ist dieses Problem entweder einfach oder gar nicht zu lösen.
Da braucht man keine Kristallkugel, bei S2S steht dir auf einer XG(S) entweder IPsec oder SSL zur Verfügung,
Amazon VPC kann die auch, aber das ist ein anderes Thema.
Würde ich zu 99% auch tippen.
Nein müssen die nicht, das kann man auch über statische Routen regeln.
Die bestimmen nur welche Routen, quasi per default, mit der entsprechenden VPN Verbindung aufgebaut werden.
Darüberhinaus kannst du bei so gut wie jedem Enterprise-VPN-Gateway, mit statischem Routing noch zusätzlich nachregeln.
Beste Grüsse aus BaWü
Alex
Beide Standorte verwenden eine Sophos XG Firewall als VPN Endpunkte.
Ist nicht relevant!diese Info ist sehr wohl wichtig, den je nach VPN-Gateway, ist dieses Problem entweder einfach oder gar nicht zu lösen.
Relevant wäre welches der zahllosen VPN Protokolle die Sophos nutzt für die VPN Kopplung, denn ein korrektes Routing der IP Netze ist ganz erheblich davon abhängig WELCHES der zahllosen VPN Protokolle verwendet wurde. Leider dazu keinerlei Auskunft so das kristallkugeln angesagt ist...
Da braucht man keine Kristallkugel, bei S2S steht dir auf einer XG(S) entweder IPsec oder SSL zur Verfügung,
Amazon VPC kann die auch, aber das ist ein anderes Thema.
Raten wir also einmal etwas im freien Fall....
Vermutlich wurde IPsec verwendet als VPN Protokoll?!
Vermutlich wurde IPsec verwendet als VPN Protokoll?!
Würde ich zu 99% auch tippen.
In der Phase 2 müssen sowohl ... und der KV Zielnetze eingetragen werden.
Nein müssen die nicht, das kann man auch über statische Routen regeln.
Die P2 SAs bestimmen bei IPsec VPNs welche IP Netze in den VPN Tunnel geroutet werden und welche nicht, sprich entscheiden also über das Routing.
Die bestimmen nur welche Routen, quasi per default, mit der entsprechenden VPN Verbindung aufgebaut werden.
Darüberhinaus kannst du bei so gut wie jedem Enterprise-VPN-Gateway, mit statischem Routing noch zusätzlich nachregeln.
Beste Grüsse aus BaWü
Alex
Hallo an alle und erst einmal vielen Dank für die vielen Antworten.
In aller Kürze geht es konkret tatsächlich um eine Arztpraxis. Bis IPSec steht die VPN.
Als Programm wird CGM Turbomed auf dem besagten Server eingesetzt. Es geht wie oben korrekt vermutet um den Einsatz von KIM.
Das Ausstellen von z. B. Impfzertfikaten funktioniert tadellos über denselben entfernten Konnektor. eGKs einlesen ist ebenfalls möglich.
KIL ist im Konnektor entsprechend freigeschaltet. KIM funktioniert auch aus anderen Praxen über denselben Konnektor - die anderen Praxen arbeiten jedoch auf Servern im Netz des Konnektors. Dort ist also keine VPN dazwischen.
Es gibt zwei Kartenterminals - beide an Standort A. Einer mit SMCB und einer mit HBA.
Das KIM Clientmodul läuft auf dem Server an Standort A.
Der Konnektor ist eine KoCoBox.
Kartenterminals und Konnektor haben aktuellsten Firmwarestand.
Ich habe Zugriff auf den Konnektor und den Server.
Detaillierte Antworten kann man vH dann am Montag geben - aber vielleicht hilft das ja schon mal. Danke und schönes WE.
In aller Kürze geht es konkret tatsächlich um eine Arztpraxis. Bis IPSec steht die VPN.
Als Programm wird CGM Turbomed auf dem besagten Server eingesetzt. Es geht wie oben korrekt vermutet um den Einsatz von KIM.
Das Ausstellen von z. B. Impfzertfikaten funktioniert tadellos über denselben entfernten Konnektor. eGKs einlesen ist ebenfalls möglich.
KIL ist im Konnektor entsprechend freigeschaltet. KIM funktioniert auch aus anderen Praxen über denselben Konnektor - die anderen Praxen arbeiten jedoch auf Servern im Netz des Konnektors. Dort ist also keine VPN dazwischen.
Es gibt zwei Kartenterminals - beide an Standort A. Einer mit SMCB und einer mit HBA.
Das KIM Clientmodul läuft auf dem Server an Standort A.
Der Konnektor ist eine KoCoBox.
Kartenterminals und Konnektor haben aktuellsten Firmwarestand.
Ich habe Zugriff auf den Konnektor und den Server.
Detaillierte Antworten kann man vH dann am Montag geben - aber vielleicht hilft das ja schon mal. Danke und schönes WE.
Moin Cykes,
der Punt geht an dich. 😉
Gruss Alex
In aller Kürze geht es konkret tatsächlich um eine Arztpraxis.
der Punt geht an dich. 😉
Gruss Alex
Moin Joh316,
😮 CGM, KIM, eGKs, KIL, SMBC, HBA (und damit ist wahrscheinlich kein FC oder SAS HBA gemeint), KoCoBox & Co KG 😬😵, ich bin raus, das ist definitiv nicht meine Baustelle.
@cykes
Sorry, das ist glaube ich doch eher deine Spezialität.
Beste Grüsse aus BaWü
Alex
Als Programm wird CGM Turbomed auf dem besagten Server eingesetzt. Es geht wie oben korrekt vermutet um den Einsatz von KIM.
Das Ausstellen von z. B. Impfzertfikaten funktioniert tadellos über denselben entfernten Konnektor. eGKs einlesen ist ebenfalls möglich.
KIL ist im Konnektor entsprechend freigeschaltet. KIM funktioniert auch aus anderen Praxen über denselben Konnektor - die anderen Praxen arbeiten jedoch auf Servern im Netz des Konnektors. Dort ist also keine VPN dazwischen.
Es gibt zwei Kartenterminals - beide an Standort A. Einer mit SMCB und einer mit HBA.
Das KIM Clientmodul läuft auf dem Server an Standort A.
Der Konnektor ist eine KoCoBox.
Kartenterminals und Konnektor haben aktuellsten Firmwarestand.
Ich habe Zugriff auf den Konnektor und den Server.
Das Ausstellen von z. B. Impfzertfikaten funktioniert tadellos über denselben entfernten Konnektor. eGKs einlesen ist ebenfalls möglich.
KIL ist im Konnektor entsprechend freigeschaltet. KIM funktioniert auch aus anderen Praxen über denselben Konnektor - die anderen Praxen arbeiten jedoch auf Servern im Netz des Konnektors. Dort ist also keine VPN dazwischen.
Es gibt zwei Kartenterminals - beide an Standort A. Einer mit SMCB und einer mit HBA.
Das KIM Clientmodul läuft auf dem Server an Standort A.
Der Konnektor ist eine KoCoBox.
Kartenterminals und Konnektor haben aktuellsten Firmwarestand.
Ich habe Zugriff auf den Konnektor und den Server.
😮 CGM, KIM, eGKs, KIL, SMBC, HBA (und damit ist wahrscheinlich kein FC oder SAS HBA gemeint), KoCoBox & Co KG 😬😵, ich bin raus, das ist definitiv nicht meine Baustelle.
@cykes
Sorry, das ist glaube ich doch eher deine Spezialität.
Beste Grüsse aus BaWü
Alex
Wobei Du zu
jetzt hättest was schlaues schreiben können - das war glaub nur ein Tippfehler und KIM war gemeint. 🤣
Btw. SMC-B ([nicht SMB-C] vulgo Praxisausweis) und HBA (Heilberufsausweis - vulgo Arztausweis) 😉
Mal schauen, was wir so ungesehen hinbekommen, CGM TurboMed hatte ich bisher auch noch nicht unter den Fingern.
Gruß
cykes
jetzt hättest was schlaues schreiben können - das war glaub nur ein Tippfehler und KIM war gemeint. 🤣
Btw. SMC-B ([nicht SMB-C] vulgo Praxisausweis) und HBA (Heilberufsausweis - vulgo Arztausweis) 😉
Mal schauen, was wir so ungesehen hinbekommen, CGM TurboMed hatte ich bisher auch noch nicht unter den Fingern.
Gruß
cykes
1Bis IPSec steht die VPN.
Ägypten?? Was soll uns dieser kryptische Satz sagen?? Mal abgesehen davon das das VPN sächlich ist...
@joh316 Es wäre erstmal hilfreich, was das eCockpit von Turbomed so sagt. Meine Vermutung: die zusätzlichen statischen Routen, die für eAU und KIM notwendig sind, fehlen entweder ganz oder landen im Nirvana.
Es ist aber auch immens wichtig, dass die Kartenleser auf aktuellem Firmwarestand sind und in der KoCoBox als gepaired auftauchen. Mittels Logfile des KIM Clientmoduls (adp*.log) auf dem Server sollte man die grundlegende Kommunikation und was dabei ggf. schiefläuft nachvollziehen können. Tipp am Rande: Immer irgendwo in der Praxis die aktuellen admin Passwörter für die Kartenleser notieren und vor allem ausprobieren. Muss das Terminal zurückgesetzt werden, muss man Ingenico bzw. jetzt Worldline kontaktieren.
Eine kleine Warnung noch: Wenn Du Dich nicht so gut mit der Materie auskennst, lass lieber die Finger davon. CGM stellt sich da immer alberner an, wenn ein DVO etwas verbastelt.
Es ist aber auch immens wichtig, dass die Kartenleser auf aktuellem Firmwarestand sind und in der KoCoBox als gepaired auftauchen. Mittels Logfile des KIM Clientmoduls (adp*.log) auf dem Server sollte man die grundlegende Kommunikation und was dabei ggf. schiefläuft nachvollziehen können. Tipp am Rande: Immer irgendwo in der Praxis die aktuellen admin Passwörter für die Kartenleser notieren und vor allem ausprobieren. Muss das Terminal zurückgesetzt werden, muss man Ingenico bzw. jetzt Worldline kontaktieren.
Eine kleine Warnung noch: Wenn Du Dich nicht so gut mit der Materie auskennst, lass lieber die Finger davon. CGM stellt sich da immer alberner an, wenn ein DVO etwas verbastelt.
Zitat von @joh316:
Wo kann hier das Problem sein, dass keine Nachrichten von Server an Standort A ins KV-Netz geschickt werden können?
Wo kann hier das Problem sein, dass keine Nachrichten von Server an Standort A ins KV-Netz geschickt werden können?
Noch einmal zum Verständnis... du hast das KIM Clientmodul erfolgreich an dem Server am Standort A installiert und hast eine Email registrieren können. Der KIM Accountmanager ist ebenfalls erreichbar?
Somit scheint ja schon einmal das Routing zu klappen, Ziel Adresse sowohl für SMTP/POP3/HTTPS(Accountmanager) sind identisch und befinden sich im 100.102.0.0/15 Netz (anders als das KVSafenet, welches sich im 188.144.0.0/16 Netz befindet).
Hast du die KIM Komponente in den anderen Praxen ebenfalls eingerichtet? Oftmal muss man in den PVS unterschiedliche Angaben machen für den SMTP/POP3 Server. Die PVS Hersteller versuchen ja IdR eigene Lösungen anzubieten und es einem schwerer bei der Konfiguration zu machen, wenn man stattdessen den KIM Client eines 'externen' Anbieters verwendet.
Am einfachsten habe ich es empfunden, wenn du ein externes Programm verwendest (z.B KV.DOX Mailclient) und hier erst einmal das Versenden und Empfangen von Emails testest.
Was sagt das Protokoll der Firewall am Standort B? Ich würde testweise die Regeln für SMTP,POP3,HTTPS für das Subnetz protokollieren lassen, um überhaupt sehen zu können, ob eine Anfrage rausgeht. Anschließend dann auch schauen ob etwas blockiert wird.
Ich habe noch einmal in meinen Firewallregeln nachgestöbert und es wird nur eine HTTPS, SMTP(465 standardmäßig) u. POP3(standard 995) Freigabe mit Ziel 100.102.x.x benötigt, zusätzlich natürlich 443 Server<>Konnektor, aber das klappt ja bereits.
Moin Cykes,
Da steht schwarz auf weis, das "KIL" im entsprechenden Konnektor freigeschaltet ist und da ich quasi
Branchenfremd bin, habe ich es nicht weiter angesprochen.
Aber du hast schon recht, eine KIL Funktion sollte man vor allem im medizinischen Umfeld, eigentlich schon besser hiterfragen. 😜
Heil-Berufs-Ausweis ... Host-Bus-Adapter ... ja, ich sehe eine gewisse Ähnlichkeit. 🤪
Wird schon werden, so wie es aussieht kennst dich in dieser Grundmaterie ziemlich gut aus.
Beste Grüsse aus BaWü
Alex
jetzt hättest was schlaues schreiben können - das war glaub nur ein Tippfehler und KIM war gemeint. 🤣
Da steht schwarz auf weis, das "KIL" im entsprechenden Konnektor freigeschaltet ist und da ich quasi
Branchenfremd bin, habe ich es nicht weiter angesprochen.
Aber du hast schon recht, eine KIL Funktion sollte man vor allem im medizinischen Umfeld, eigentlich schon besser hiterfragen. 😜
Btw. SMC-B ([nicht SMB-C] vulgo Praxisausweis)
Ups, da habe ich mich verschrieben. 🙃und HBA (Heilberufsausweis - vulgo Arztausweis) 😉
Heil-Berufs-Ausweis ... Host-Bus-Adapter ... ja, ich sehe eine gewisse Ähnlichkeit. 🤪
Mal schauen, was wir so ungesehen hinbekommen, CGM TurboMed hatte ich bisher auch noch nicht unter den Fingern.
Wird schon werden, so wie es aussieht kennst dich in dieser Grundmaterie ziemlich gut aus.
Beste Grüsse aus BaWü
Alex
Zitat von @jktz84:
Noch einmal zum Verständnis... du hast das KIM Clientmodul erfolgreich an dem Server am Standort A installiert und hast eine Email registrieren können. Der KIM Accountmanager ist ebenfalls erreichbar?
Ja. Korrekt.Noch einmal zum Verständnis... du hast das KIM Clientmodul erfolgreich an dem Server am Standort A installiert und hast eine Email registrieren können. Der KIM Accountmanager ist ebenfalls erreichbar?
Somit scheint ja schon einmal das Routing zu klappen, Ziel Adresse sowohl für SMTP/POP3/HTTPS(Accountmanager) sind identisch und befinden sich im 100.102.0.0/15 Netz (anders als das KVSafenet, welches sich im 188.144.0.0/16 Netz befindet).
Exakt.Was sagt das Protokoll der Firewall am Standort B? Ich würde testweise die Regeln für SMTP,POP3,HTTPS für das Subnetz protokollieren lassen, um überhaupt sehen zu können, ob eine Anfrage rausgeht. Anschließend dann auch schauen ob etwas blockiert wird.
Die Anfragen gehen erfolgreich raus an Standort B - Port 443, 995 und 465 werden angefragt und entsprechend durchgelassen.Interesant ist, dass das Empfangen von Nachrichten im KIM funktioniert - nur eben das Senden nicht.
Das KIM wurde direkt durch den TurboMed Support bereits mehrfach installiert - ich würde also mal vorsichtig ausschließen, dass das Problem in der Installation liegt.
An den anderen Standorten wird nicht TurboMed verwendet - daher haben wir leider kein Vergleichsobjekt.
Zitat von @cykes:
@joh316 Es wäre erstmal hilfreich, was das eCockpit von Turbomed so sagt. Meine Vermutung: die zusätzlichen statischen Routen, die für eAU und KIM notwendig sind, fehlen entweder ganz oder landen im Nirvana.
Die Routen sind am Server und in der Sophos am Standort B hinterlegt:@joh316 Es wäre erstmal hilfreich, was das eCockpit von Turbomed so sagt. Meine Vermutung: die zusätzlichen statischen Routen, die für eAU und KIM notwendig sind, fehlen entweder ganz oder landen im Nirvana.
188.144.0.0 /16 über [IP des Konnektors an Standort B]
100.102.0.0 /15 über [IP des Konnektors an Standort B]
Es ist aber auch immens wichtig, dass die Kartenleser auf aktuellem Firmwarestand sind und in der KoCoBox als gepaired auftauchen.
Firmware ist sowohl auf der Kocobox, als auch an den Kartenlesern auf aktuellstem Stand. In der Kocobox erscheinen die Kartenleser als aktiv.Mittels Logfile des KIM Clientmoduls (adp*.log) auf dem Server sollte man die grundlegende Kommunikation und was dabei ggf. schiefläuft nachvollziehen können.
Ich kann ein derartiges Logfile mit dieser Bezeichnung am Anfang leider nicht finden.Zitat von @joh316:
Ich kann ein derartiges Logfile mit dieser Bezeichnung am Anfang leider nicht finden.
Ich kann ein derartiges Logfile mit dieser Bezeichnung am Anfang leider nicht finden.
Für mich klingt das eher nach fehlerhafter Einrichtung in der PVS. Ich würde ja immer noch dazu raten die KIM Funktion erst einmal mit einem externen Mail Client zu testen.
Die Log Dateien müsstest du eig. auch im KIM Client Modul einsehen können. Hier findest du dann Hinweise auf fehlerhafte Anfragen.
genau.
Die Sophos an Standort B läuft im MTA-Modus (Liegt hier vielleicht eine Besonderheit?)
Willst du die Mail an ein Ziel innerhalb des KVN's verschicken oder über das LRZ nach aussen?
Läuft die XG SMTP technisch am Standort B als MTA oder im Legacy-Modus?
Die Mail wird an ein Ziel innerhalb des KV-Netzes verschickt.Läuft die XG SMTP technisch am Standort B als MTA oder im Legacy-Modus?
Die Sophos an Standort B läuft im MTA-Modus (Liegt hier vielleicht eine Besonderheit?)
Moin Joh316,
Die Sophos an Standort B läuft im MTA-Modus (Liegt hier vielleicht eine Besonderheit?)
🤔, das kann gut sein.
Im MTA Modus, verschickt man die Mails Quasi nicht durch die XG ins WAN und oder andere Transfernetze,
sondern übergibt diese an die XG und die leitet diese, gemäss ihrem eigenen DNS und Routing, an das entsprechende Ziel weiter. Sprich, im MTA Modus sollte als SMTP Server bei internen Applikationen, am besten immer die XG selbst angegeben werden.
Wenn du durch die XG, quasi transparent per SMTP "durchschiessen" möchtest, dann solltest du eher den Legacy Modus wählen. Aber bevor du das versuchst, gehen abgesehen von dem bisher angesprochenen Anwendungsfall, den sonst noch Mails durch die XG, z.B. interner Exchange oder noch weitere Applikationen die SMTP verwenden?
Beste Grüsse aus BaWü
Alex
Willst du die Mail an ein Ziel innerhalb des KVN's verschicken oder über das LRZ nach aussen?
Läuft die XG SMTP technisch am Standort B als MTA oder im Legacy-Modus?
Die Mail wird an ein Ziel innerhalb des KV-Netzes verschickt.Läuft die XG SMTP technisch am Standort B als MTA oder im Legacy-Modus?
Die Sophos an Standort B läuft im MTA-Modus (Liegt hier vielleicht eine Besonderheit?)
🤔, das kann gut sein.
Im MTA Modus, verschickt man die Mails Quasi nicht durch die XG ins WAN und oder andere Transfernetze,
sondern übergibt diese an die XG und die leitet diese, gemäss ihrem eigenen DNS und Routing, an das entsprechende Ziel weiter. Sprich, im MTA Modus sollte als SMTP Server bei internen Applikationen, am besten immer die XG selbst angegeben werden.
Wenn du durch die XG, quasi transparent per SMTP "durchschiessen" möchtest, dann solltest du eher den Legacy Modus wählen. Aber bevor du das versuchst, gehen abgesehen von dem bisher angesprochenen Anwendungsfall, den sonst noch Mails durch die XG, z.B. interner Exchange oder noch weitere Applikationen die SMTP verwenden?
Beste Grüsse aus BaWü
Alex
Wenn du durch die XG, quasi transparent per SMTP "durchschiessen" möchtest, dann solltest du eher den Legacy Modus wählen. Aber bevor du das versuchst, gehen abgesehen von dem bisher angesprochenen Anwendungsfall, den sonst noch Mails durch die XG, z.B. interner Exchange oder noch weitere Applikationen die SMTP verwenden?
Wir nutzen einen Exchange-Server, aber der Versand wird dann letztlich über die Sophos abgewickelt.Diverse Smartphones mit Mail-Client nutzen noch SMTP - das funktioniert problemlos.
Kann es sein, dass ich in den Relay-Einstellungen (https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/de-de/webhelp/onli ..) den Server im entfernten Netz (Standort A) ergänzen muss? Dort ist aktuell nur unser Excahnge drin.
Moin Joh316,
Diverse Smartphones mit Mail-Client nutzen noch SMTP - das funktioniert problemlos.
OK, dann solltest du auf jeden Fall nicht auf den Legacy wechseln.
Wenn du den MTA der Sophos korrekt nutzen möchtest, dann musst du in den Med-App als SMTP das entsprechende interne XG Beinchen eintragen. Die XG wiederum muss die entsprechende Zieldomäne der Mail, respektive deren MX korrekt auflösen können und das Routing müsste dann zu dem entsprechenden Ziel-SMTP (KVN) auf der XG auch noch stimmen. Und ja, den Quell-SMTP (Med-App) musst du in der XG zum Relay auch freigeben, weil dieser durch die XG über KVN ja quasi nach Extern verschicken möchte.
Ich hoffe das war jetzt nicht zu verwirrend, bin heute erst bei dem dritten Kaffee, sprich, noch nicht ganz vollständig wach. 🤪
Beste Grüsse aus BaWü
Alex
P.S.
Fast vergessen, auf der XG in der entsprechenden Netzwerk-Zone die dem Netzwerk in dem sich die Med-App befindet, musst das das SMTP-Relay auch aktivieren.
P.S.P.S.
Ähm, hast du auf der XG SD-WAN in Betrieb?
Wenn du durch die XG, quasi transparent per SMTP "durchschiessen" möchtest, dann solltest du eher den Legacy Modus wählen. Aber bevor du das versuchst, gehen abgesehen von dem bisher angesprochenen Anwendungsfall, den sonst noch Mails durch die XG, z.B. interner Exchange oder noch weitere Applikationen die SMTP verwenden?
Wir nutzen einen Exchange-Server, aber der Versand wird dann letztlich über die Sophos abgewickelt.Diverse Smartphones mit Mail-Client nutzen noch SMTP - das funktioniert problemlos.
OK, dann solltest du auf jeden Fall nicht auf den Legacy wechseln.
Kann es sein, dass ich in den Relay-Einstellungen (https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/de-de/webhelp/onli ..) den Server im entfernten Netz (Standort A) ergänzen muss? Dort ist aktuell nur unser Excahnge drin.
Wenn du den MTA der Sophos korrekt nutzen möchtest, dann musst du in den Med-App als SMTP das entsprechende interne XG Beinchen eintragen. Die XG wiederum muss die entsprechende Zieldomäne der Mail, respektive deren MX korrekt auflösen können und das Routing müsste dann zu dem entsprechenden Ziel-SMTP (KVN) auf der XG auch noch stimmen. Und ja, den Quell-SMTP (Med-App) musst du in der XG zum Relay auch freigeben, weil dieser durch die XG über KVN ja quasi nach Extern verschicken möchte.
Ich hoffe das war jetzt nicht zu verwirrend, bin heute erst bei dem dritten Kaffee, sprich, noch nicht ganz vollständig wach. 🤪
Beste Grüsse aus BaWü
Alex
P.S.
Fast vergessen, auf der XG in der entsprechenden Netzwerk-Zone die dem Netzwerk in dem sich die Med-App befindet, musst das das SMTP-Relay auch aktivieren.
P.S.P.S.
Ähm, hast du auf der XG SD-WAN in Betrieb?
Zitat von @MysticFoxDE:
Wenn du den MTA der Sophos korrekt nutzen möchtest, dann musst du in den Med-App als SMTP das entsprechende interne XG Beinchen eintragen. Die XG wiederum muss die entsprechende Zieldomäne der Mail, respektive deren MX korrekt auflösen können und das Routing müsste dann zu dem entsprechenden Ziel-SMTP (KVN) auf der XG auch noch stimmen. Und ja, den Quell-SMTP (Med-App) musst du in der XG zum Relay auch freigeben, weil dieser durch die XG über KVN ja quasi nach Extern verschicken möchte.
Ich hoffe das war jetzt nicht zu verwirrend, bin heute erst bei dem dritten Kaffee, sprich, noch nicht ganz vollständig wach. 🤪
Danke für deine ausführlichen Antworten - hier muss ich mich erstmal eindenken...Wenn du den MTA der Sophos korrekt nutzen möchtest, dann musst du in den Med-App als SMTP das entsprechende interne XG Beinchen eintragen. Die XG wiederum muss die entsprechende Zieldomäne der Mail, respektive deren MX korrekt auflösen können und das Routing müsste dann zu dem entsprechenden Ziel-SMTP (KVN) auf der XG auch noch stimmen. Und ja, den Quell-SMTP (Med-App) musst du in der XG zum Relay auch freigeben, weil dieser durch die XG über KVN ja quasi nach Extern verschicken möchte.
Ich hoffe das war jetzt nicht zu verwirrend, bin heute erst bei dem dritten Kaffee, sprich, noch nicht ganz vollständig wach. 🤪
Fast vergessen, auf der XG in der entsprechenden Netzwerk-Zone die dem Netzwerk in dem sich die Med-App befindet, musst das das SMTP-Relay auch aktivieren.
Danke für den Hinweis.Ähm, hast du auf der XG SD-WAN in Betrieb?
Ja, tatsächlich ist SD-WAN in Benutzung:Quelle Exchange Server ->In beliebige Netze mit den Diensten SMTP und SMTPs -> über unseren ISP.
Moin Joh316,
da könnte der Hund auch schon begraben sein, den du möchtest in dem angesprochenen Fall die Mails ja nicht wirklich über den ISP rausjagen, sondern durch das KVN. 😉
Schau mal während du versuchst eine Mail zu verschicken, in der Verbindungsübersicht der XG nach, welche Verbindungen und vor allem WAN-Gateways benutzt werden.
🤔, wie ist den die Routing-Reihenfolge deiner XG's konfiguriert?
Kann es sein dass die auf ...
SD-WAN-Route --> Statische Route --> VPN-Route
oder
SD-WAN-Route --> VPN-Route --> Statische Route
gestellt ist?
Wenn ja, bitte auf ...
Statische Route --> VPN-Route --> SD-WAN-Route
ändern.
Beste Grüsse aus BaWü
Alex
Quelle Exchange Server ->In beliebige Netze mit den Diensten SMTP und SMTPs -> über unseren ISP.
da könnte der Hund auch schon begraben sein, den du möchtest in dem angesprochenen Fall die Mails ja nicht wirklich über den ISP rausjagen, sondern durch das KVN. 😉
Schau mal während du versuchst eine Mail zu verschicken, in der Verbindungsübersicht der XG nach, welche Verbindungen und vor allem WAN-Gateways benutzt werden.
🤔, wie ist den die Routing-Reihenfolge deiner XG's konfiguriert?
Kann es sein dass die auf ...
SD-WAN-Route --> Statische Route --> VPN-Route
oder
SD-WAN-Route --> VPN-Route --> Statische Route
gestellt ist?
Wenn ja, bitte auf ...
Statische Route --> VPN-Route --> SD-WAN-Route
ändern.
Beste Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Schau mal während du versuchst eine Mail zu verschicken, in der Verbindungsübersicht der XG nach, welche Verbindungen und vor allem WAN-Gateways benutzt werden.
Die Verbindungsliste am Standort B sieht ok aus - das Paket kommt über IPSec rein, geht an Port 3 raus (An diesem Port ist auch der Konnektor angeschlossen). Die Ziel-IP ist im 100.102er Netz. Zugehörige NAT-Regel ist auch, wie erwartet.Schau mal während du versuchst eine Mail zu verschicken, in der Verbindungsübersicht der XG nach, welche Verbindungen und vor allem WAN-Gateways benutzt werden.
Am Standort A sieht die Verbindung auch OK aus - dort wird angezeigt, dass keine NAT-Regel zum Einsatz kommt. Ist das korrekt so oder sollte für den Fall auch ein SNAT (MASQ) am Standort A hinterlegt werden?
🤔, wie ist den die Routing-Reihenfolge deiner XG's konfiguriert?
Kann es sein dass die auf ...
SD-WAN-Route --> Statische Route --> VPN-Route
oder
SD-WAN-Route --> VPN-Route --> Statische Route
gestellt ist?
Wenn ja, bitte auf ...
Statische Route --> VPN-Route --> SD-WAN-Route
ändern.
Die Reihenfolge ist tatsächlich so eingestellt:Kann es sein dass die auf ...
SD-WAN-Route --> Statische Route --> VPN-Route
oder
SD-WAN-Route --> VPN-Route --> Statische Route
gestellt ist?
Wenn ja, bitte auf ...
Statische Route --> VPN-Route --> SD-WAN-Route
ändern.
SD-WAN-Richtlinienroute, VPN-Route, Statische Route.
Ich glaube, ich verstehe da gerade etwas falsch:
Wenn ich alles, was vom Exchange kommt in Richtung beliebiger Netze mit SMTP/SMTPs über den ISP rauslasse, dann betrifft das doch eigentlich unseren Problemfall nicht - dort ist die Quelle ja nicht der Exchange, sondern ein Host in einem entfernten Netz. Oder springt die SD-WAN Route schon an, wenn nur die genutzten Dienste übereinstimmen?
Danke für deine Geduld ;)
Moin Joh,
Nein vom Standort A benötigst du keine SNAT Richtung Standort B.
S-NAT benötigst du, wenn ich dein Konstrukt auch nur halbwegs richtig verstehe, nur am Standort B.
Sind die IP Adressen am Standort B, vom KVN Betreiber vorgegeben?
Für mich zum Verständnis, wofür steht in der medizinischen IT-Branche das KVN genau?
😬, des isch nix gut, bitte auf "Statische Route --> VPN-Route --> SD-WAN-Route".
Ich verstehe überhaupt nicht, wie Sophos auf die Idee kommt, diese dämliche Routingreihenfolge, per Default zu implementieren. 😠
Ich habe das Thema schon x Mal mit dem Support von Sophos besprochen gehabt und selbst der kann das nicht nachvollziehen und hat selbst nur Probleme damit.
Das hängt von zwei Faktoren ab, der Routingreihenfolge und hier erfüllst du bereits die Kriterien, dass SD-WAN dazwischenfunkt.
Dar zweite Faktor ist das SD-WAN Regelwerk. Wenn du hier nur eine Regel alla "von any mit SMTP nach any" hast,
dann hast du auch die zweite Voraussetzung erfüllt und SD-WAN geht definitiv dazwischen.
Gern geschehen.
Beste Grüsse aus BaWü
Alex
Am Standort A sieht die Verbindung auch OK aus - dort wird angezeigt, dass keine NAT-Regel zum Einsatz kommt. Ist das korrekt so oder sollte für den Fall auch ein SNAT (MASQ) am Standort A hinterlegt werden?
Nein vom Standort A benötigst du keine SNAT Richtung Standort B.
S-NAT benötigst du, wenn ich dein Konstrukt auch nur halbwegs richtig verstehe, nur am Standort B.
Sind die IP Adressen am Standort B, vom KVN Betreiber vorgegeben?
Für mich zum Verständnis, wofür steht in der medizinischen IT-Branche das KVN genau?
Die Reihenfolge ist tatsächlich so eingestellt:
SD-WAN-Richtlinienroute, VPN-Route, Statische Route.
SD-WAN-Richtlinienroute, VPN-Route, Statische Route.
😬, des isch nix gut, bitte auf "Statische Route --> VPN-Route --> SD-WAN-Route".
Ich verstehe überhaupt nicht, wie Sophos auf die Idee kommt, diese dämliche Routingreihenfolge, per Default zu implementieren. 😠
Ich habe das Thema schon x Mal mit dem Support von Sophos besprochen gehabt und selbst der kann das nicht nachvollziehen und hat selbst nur Probleme damit.
Oder springt die SD-WAN Route schon an, wenn nur die genutzten Dienste übereinstimmen?
Das hängt von zwei Faktoren ab, der Routingreihenfolge und hier erfüllst du bereits die Kriterien, dass SD-WAN dazwischenfunkt.
Dar zweite Faktor ist das SD-WAN Regelwerk. Wenn du hier nur eine Regel alla "von any mit SMTP nach any" hast,
dann hast du auch die zweite Voraussetzung erfüllt und SD-WAN geht definitiv dazwischen.
Danke für deine Geduld ;)
Gern geschehen.
Beste Grüsse aus BaWü
Alex
Also ich warte nun schon einige Zeit auf Rückmeldung, wo im TurboMed der SMTP Server separat eingestellt werden kann, damit der Versand über das "Beinchen der Sophos" erfolgen kann. Leider habe ich dazu bisher keine Info bekommen. Warten wir mal ab...
Nein.
Nun erst einmal schönes Pfingstwochenende.
Nein.
Für mich zum Verständnis, wofür steht in der medizinischen IT-Branche das KVN genau?
Alle Abwicklungen zu den Krankenkassen / direkt zur Kassenärztlichen Vereinigung werden über dieses Netz durchgeführt.😬, des isch nix gut, bitte auf "Statische Route --> VPN-Route --> SD-WAN-Route".
Ist erledigt - der Fehler bleibt jedoch bestehen.Nun erst einmal schönes Pfingstwochenende.
Moin Joh316,
ähm, das musst du nicht unbedingt in dem TurboMed umstellen.
Du kannst ja mal rausfieseln zu welchem SMTP Server die App die Verbindung aufbaut und dann nattest du am Standort A per DNAT den SMTP Verkehr Richtung KVN, einfach auf das interne Beinchen der Sophos am Standort B um und schon müsste der Fisch geputzt sein. 😎
😮, OK, dann verstehe ich das Routingkonzept von dem Med-KVN doch nicht so ganz.
Musst du alles Richtung KVN mit einer bestimmten IP-Adresse natten?
Wünsche ich dir auch.
Beste Grüsse aus BaWü
Alex
Also ich warte nun schon einige Zeit auf Rückmeldung, wo im TurboMed der SMTP Server separat eingestellt werden kann, damit der Versand über das "Beinchen der Sophos" erfolgen kann. Leider habe ich dazu bisher keine Info bekommen. Warten wir mal ab...
ähm, das musst du nicht unbedingt in dem TurboMed umstellen.
Du kannst ja mal rausfieseln zu welchem SMTP Server die App die Verbindung aufbaut und dann nattest du am Standort A per DNAT den SMTP Verkehr Richtung KVN, einfach auf das interne Beinchen der Sophos am Standort B um und schon müsste der Fisch geputzt sein. 😎
Nein.
😮, OK, dann verstehe ich das Routingkonzept von dem Med-KVN doch nicht so ganz.
Musst du alles Richtung KVN mit einer bestimmten IP-Adresse natten?
Nun erst einmal schönes Pfingstwochenende.
Wünsche ich dir auch.
Beste Grüsse aus BaWü
Alex
Zitat von @joh316:
Also ich warte nun schon einige Zeit auf Rückmeldung, wo im TurboMed der SMTP Server separat eingestellt werden kann, damit der Versand über das "Beinchen der Sophos" erfolgen kann. Leider habe ich dazu bisher keine Info bekommen. Warten wir mal ab...
Also ich warte nun schon einige Zeit auf Rückmeldung, wo im TurboMed der SMTP Server separat eingestellt werden kann, damit der Versand über das "Beinchen der Sophos" erfolgen kann. Leider habe ich dazu bisher keine Info bekommen. Warten wir mal ab...
Als SMTP Server dient derjenige Server, auf dem das KIM Clientmodul installiert ist. Entsprechend wird in der PVS die lokale Serveradresse angegeben.
Das KIM Clientmodul wiederum baut dann eine Verbindung zum Fachdienst in der TI auf.
Schau dir noch einmal das KIM Clientmodul an. Lass dir hier die Logs anzeigen. Benutz einen externen Mail Client (z.B kv.dox Email Client) um die Verbindungen zum Clientmodul und zu den Komponenten der TI zu testen.
Moin,
ich misch mich auch mal wieder ein
Ich glaube nicht, dass es dem Clientmodul gefällt, wenn da noch ein Mailproxy auf dem Weg dazwischengeschaltet ist.
Gruß
cykes
ich misch mich auch mal wieder ein
Ich glaube nicht, dass es dem Clientmodul gefällt, wenn da noch ein Mailproxy auf dem Weg KIM-Mailclient -> KIM-Clientmodul -> VPN -> Mailproxy Standort B (Sophos) -> Konnektor -> KIM-FachdienstGruß
cykes
Zitat von @MysticFoxDE:
😮, OK, dann verstehe ich das Routingkonzept von dem Med-KVN doch nicht so ganz.
Musst du alles Richtung KVN mit einer bestimmten IP-Adresse natten?
Mach Dir keinen Kopp 😮, OK, dann verstehe ich das Routingkonzept von dem Med-KVN doch nicht so ganz.
Musst du alles Richtung KVN mit einer bestimmten IP-Adresse natten?
Ich glaube, das Konzept versteht nicht mal die Gematik und die Umsetzung noch viel weniger 1
Also kurze Rückmeldung:
Eure genannten Vorschläge haben wir nun alle versucht - leider bisher erfolglos.
Wir suchen weiter nach einer Lösung für das Problem.
Sollte es sich zwischenrein klären, werde ich gern die Lösung hier für die Nachwelt posten.
Eure genannten Vorschläge haben wir nun alle versucht - leider bisher erfolglos.
Wir suchen weiter nach einer Lösung für das Problem.
Sollte es sich zwischenrein klären, werde ich gern die Lösung hier für die Nachwelt posten.
1
Wenn es das denn nun war bitte dann auch deinen Thread hier als erledigt schliessen!
Hallo zurück. Das Problem ist leider bisher ungelöst. Wir haben zumindest das Routing überprüfen lassen. Da ist alles sauber. Es kommen auch Antwortpakete an das richtige Ziel, aber dennoch nicht funktionstüchtig.
Der Fehler ist dann meistens eine Firewall oder lokale Firewall die einseitig den Traffic Flow filtert oder blockt.
Zitat von @jktz84:
Schau dir noch einmal das KIM Clientmodul an. Lass dir hier die Logs anzeigen. Benutz einen externen Mail Client (z.B kv.dox Email Client) um die Verbindungen zum Clientmodul und zu den Komponenten der TI zu testen.
Schau dir noch einmal das KIM Clientmodul an. Lass dir hier die Logs anzeigen. Benutz einen externen Mail Client (z.B kv.dox Email Client) um die Verbindungen zum Clientmodul und zu den Komponenten der TI zu testen.
Ich habe in der Zwischenzeit die Anbindung über Thunderbird getestet.
Der Mailempfang funktioniert einwandfrei.
Der Versand schlägt genauso fehl mit Fehlercode 421 (Service not available, closing transmission channel.)
Die Verbindung zwischen Thunderbird und KIM ClientModul ist offenbar intakt, denn da werden keine Zugangsdaten bemängelt. Die Pakete kann ich auch nachvollziehen an Seite B. Antworten kommen zurück zur Seite A.
Lokal am Server an Seite A habe ich die lokale Firewall ganz deaktiviert. Virenschutz ist derzeit keiner installiert.
Ich habe langsam keine Idee mehr...
Im Thunderbird erscheint zunächst die Meldung, die ich mal noch angehangen habe - das sieht alles normal aus.
Danach erscheint besagte Fehlermeldung.
Wir haben zumindest das Routing überprüfen lassen. Da ist alles sauber.
WIE hast du das denn genau überprüfen lassen. Und warum "lassen"? Sinnvoller ist doch du machst das selber als es anderen zu überlassen die ggf. keine Kentnisse davon haben.Zitat von @aqui:
Wir haben zumindest das Routing überprüfen lassen. Da ist alles sauber.
WIE hast du das denn genau überprüfen lassen. Und warum "lassen"? Sinnvoller ist doch du machst das selber als es anderen zu überlassen die ggf. keine Kentnisse davon haben.Ich habe eine Fernwartung mit einem externen Dienstleister durchgeführt, wir haben den Weg zusammen nachvollzogen. Ich kannte die Gegenstellen und Ports und der DL hat geprüft, ob die Pakete den richtigen Weg gehen.
Der Weg war korrekt - ich war mir niur nicht sicher, ob ich eine Feinheit übersehen habe, da ich mir den Fehler langsam nicht mehr erklären kann - daher die Hilfe von extern.
OK, wenn man das Routing wirklich sicherstellen kann dann musst du mit dem Wireshark ran.
Du musst den Sendeprozess einmal aufzeichnen und zwar am Client und auch am Empfänger (Server). Idealerweise macht man das parallel und checkt WO es genau abbricht.
Mit so einem Trace hat man dann zu 98% ein Indiz was genau der Fehler ist.
Du musst den Sendeprozess einmal aufzeichnen und zwar am Client und auch am Empfänger (Server). Idealerweise macht man das parallel und checkt WO es genau abbricht.
Mit so einem Trace hat man dann zu 98% ein Indiz was genau der Fehler ist.
Moin joh316,
Ich habe eine Fernwartung mit einem externen Dienstleister durchgeführt, wir haben den Weg zusammen nachvollzogen. Ich kannte die Gegenstellen und Ports und der DL hat geprüft, ob die Pakete den richtigen Weg gehen.
Der Weg war korrekt - ich war mir niur nicht sicher, ob ich eine Feinheit übersehen habe, da ich mir den Fehler langsam nicht mehr erklären kann - daher die Hilfe von extern.
verwendest du auf den beiden XG's rein zufällig schon die neue SSL/TLS Inspection Engine?
Wenn ja, hast du hier eine Ausnahme konfiguriert, die sicherstellt, dass der SMTP Verkehr von dieser Engine nicht angefasst wird?
Beste Grüsse aus BaWü
Alex
Wir haben zumindest das Routing überprüfen lassen. Da ist alles sauber.
WIE hast du das denn genau überprüfen lassen. Und warum "lassen"? Sinnvoller ist doch du machst das selber als es anderen zu überlassen die ggf. keine Kentnisse davon haben.Ich habe eine Fernwartung mit einem externen Dienstleister durchgeführt, wir haben den Weg zusammen nachvollzogen. Ich kannte die Gegenstellen und Ports und der DL hat geprüft, ob die Pakete den richtigen Weg gehen.
Der Weg war korrekt - ich war mir niur nicht sicher, ob ich eine Feinheit übersehen habe, da ich mir den Fehler langsam nicht mehr erklären kann - daher die Hilfe von extern.
verwendest du auf den beiden XG's rein zufällig schon die neue SSL/TLS Inspection Engine?
Wenn ja, hast du hier eine Ausnahme konfiguriert, die sicherstellt, dass der SMTP Verkehr von dieser Engine nicht angefasst wird?
Beste Grüsse aus BaWü
Alex
1Zitat von @aqui
OK, wenn man das Routing wirklich sicherstellen kann dann musst du mit dem Wireshark ran.
OK.OK, wenn man das Routing wirklich sicherstellen kann dann musst du mit dem Wireshark ran.
Zitat von @MysticFoxDE:
verwendest du auf den beiden XG's rein zufällig schon die neue SSL/TLS Inspection Engine?
Wenn ja, hast du hier eine Ausnahme konfiguriert, die sicherstellt, dass der SMTP Verkehr von dieser Engine nicht angefasst wird?
verwendest du auf den beiden XG's rein zufällig schon die neue SSL/TLS Inspection Engine?
Wenn ja, hast du hier eine Ausnahme konfiguriert, die sicherstellt, dass der SMTP Verkehr von dieser Engine nicht angefasst wird?
Die SSL/TLS Inspection Engine ist auf beiden Seiten ausgeschalten.
Moin joh316,
🤔, ich werde irgendwie das Gefühl nicht los, dass dir hier doch die XG's dazwischenfunken.
Hast du schon mal direkt per Console auf die SMTP Logs (awarrensmtp.log, awarrenmta.log) der XG's geschaut?
Gruss Alex
Die SSL/TLS Inspection Engine ist auf beiden Seiten ausgeschalten.
🤔, ich werde irgendwie das Gefühl nicht los, dass dir hier doch die XG's dazwischenfunken.
Hast du schon mal direkt per Console auf die SMTP Logs (awarrensmtp.log, awarrenmta.log) der XG's geschaut?
Gruss Alex
Zitat von @MysticFoxDE:
Hast du schon mal direkt per Console auf die SMTP Logs (awarrensmtp.log, awarrenmta.log) der XG's geschaut?
Hast du schon mal direkt per Console auf die SMTP Logs (awarrensmtp.log, awarrenmta.log) der XG's geschaut?
Guten Morgen,
ich habe eben auf beiden XG nachgesehen:
Auf Seite A in awarrensmtp.log bzw. smtpd_main.log bzw. smtpd_error.log wird nichts aufgeführt, wenn ich die Mail lossende. Auf Seite A erhalte ich in smtpd_main.log lediglich immer wiederkehrend die Auskunft:
19094 1 queue-runner process runningAuf Seite B in smtpd_main.log bzw. smtpd_error.log sehe ich EInträgfe zu Mails, die ich zuordnen kann. Jedoch zu besagter Mail von Standort A ist kein Eintrag verzeichnet.
awarrenmta.log gibt es nicht mehr, ist jetzt smtpd.log:
https://docs.sophos.com/nsg/sophos-firewall/19.0/Help/en-us/webhelp/onli ...
Finde ich jetzt ehrlich gesagt sehr komisch, dass die Kommunikation dort gar nicht auftaucht, denn auf Seite B kann ich ja in der Paketverfolgung in der GUI sehen, dass die Pakete an die KV-IP über den Konnektor gehen und von Seite A kommen?!
Hast du noch eine Idee dazu?
Moin joh316,
kommt dieser Eintrag immer dann, wenn du versuchts am Standort A einem Mail Richtung KVN zu verschicken?
Die SMTP Logs der XG's dürfen bei dieser Mailübermittlung überhaupt nicht zucken!
Sobald das der Falls ist, ist das ein sicheres Indiz, das der MTA dazwischengeht.
Danke für die Info, das ist mir bisher entgangen.
Wenn du die SMTP Logs meinst, dann passt das schon.
Wie ich oben schon geschrieben habe, musst du in deinem Fall vermeiden, dass die XG's mit Ihren MTA's dazwischenfunken. So wie ich das verstanden habe, benötigst du lediglich ein funktionierendes IP-Routing und etwas NAT bis zum Ziel und kein Mail-ALG das aktiv dazwischengeht.
Ja, leider nicht nur eine. 🙃
Hast du die NAT-Regeln auf der XG am Standort B manuell oder per Assistent angelegt?
Beste Grüsse aus BaWü
Alex
Auf Seite A in awarrensmtp.log bzw. smtpd_main.log bzw. smtpd_error.log wird nichts aufgeführt, wenn ich die Mail lossende. Auf Seite A erhalte ich in smtpd_main.log lediglich immer wiederkehrend die Auskunft:
19094 1 queue-runner process runningkommt dieser Eintrag immer dann, wenn du versuchts am Standort A einem Mail Richtung KVN zu verschicken?
Auf Seite B in smtpd_main.log bzw. smtpd_error.log sehe ich EInträgfe zu Mails, die ich zuordnen kann. Jedoch zu besagter Mail von Standort A ist kein Eintrag verzeichnet.
Die SMTP Logs der XG's dürfen bei dieser Mailübermittlung überhaupt nicht zucken!
Sobald das der Falls ist, ist das ein sicheres Indiz, das der MTA dazwischengeht.
awarrenmta.log gibt es nicht mehr, ist jetzt smtpd.log:
https://docs.sophos.com/nsg/sophos-firewall/19.0/Help/en-us/webhelp/onli ...
https://docs.sophos.com/nsg/sophos-firewall/19.0/Help/en-us/webhelp/onli ...
Danke für die Info, das ist mir bisher entgangen.
Finde ich jetzt ehrlich gesagt sehr komisch, dass die Kommunikation dort gar nicht auftaucht, denn auf Seite B kann ich ja in der Paketverfolgung in der GUI sehen, dass die Pakete an die KV-IP über den Konnektor gehen und von Seite A kommen?!
Wenn du die SMTP Logs meinst, dann passt das schon.
Wie ich oben schon geschrieben habe, musst du in deinem Fall vermeiden, dass die XG's mit Ihren MTA's dazwischenfunken. So wie ich das verstanden habe, benötigst du lediglich ein funktionierendes IP-Routing und etwas NAT bis zum Ziel und kein Mail-ALG das aktiv dazwischengeht.
Hast du noch eine Idee dazu?
Ja, leider nicht nur eine. 🙃
Hast du die NAT-Regeln auf der XG am Standort B manuell oder per Assistent angelegt?
Beste Grüsse aus BaWü
Alex
Guten Morgen,
Als Erinnerung: Standort A kein MTA, Standort B MTA
Mit Anlegen der Firewallregel für den Verkehr von Standort A nach KVN (Dienst beliebig) habe ich eine verknüpfte NAT Regel erstellt, die einzige Änderung, die ich dort vorgenommen habe ist:
Beste Grüße und einen angenehmen Tag.
Zitat von @MysticFoxDE:
kommt dieser Eintrag immer dann, wenn du versuchts am Standort A einem Mail Richtung KVN zu verschicken?
Nein, der Eintrag kommt automatisch aller ca. 15 Sekunden.19094 1 queue-runner process runningDie SMTP Logs der XG's dürfen bei dieser Mailübermittlung überhaupt nicht zucken!
Sobald das der Falls ist, ist das ein sicheres Indiz, das der MTA dazwischengeht.
Sehr gut, dann funkt der MTA Modus ja schon mal nicht dazwischen, da in den Logs nichts von der Übertragung auftaucht.Sobald das der Falls ist, ist das ein sicheres Indiz, das der MTA dazwischengeht.
Als Erinnerung: Standort A kein MTA, Standort B MTA
Wie ich oben schon geschrieben habe, musst du in deinem Fall vermeiden, dass die XG's mit Ihren MTA's dazwischenfunken. So wie ich das verstanden habe, benötigst du lediglich ein funktionierendes IP-Routing und etwas NAT bis zum Ziel und kein Mail-ALG das aktiv dazwischengeht.
Das ist korrekt.Hast du die NAT-Regeln auf der XG am Standort B manuell oder per Assistent angelegt?
Ich sag mal halbautomatisch ;)Mit Anlegen der Firewallregel für den Verkehr von Standort A nach KVN (Dienst beliebig) habe ich eine verknüpfte NAT Regel erstellt, die einzige Änderung, die ich dort vorgenommen habe ist:
Quelle: MASQBeste Grüße und einen angenehmen Tag.
Der Vollständigkeit halber sende ich mal noch einen Auszug aus "\TurboMed\Programm\communicator\log\Communicator.log"
Die persönlichen Praxisdaten wurden anonymisiert, ist kein Fehler (max.musterarzt@tm.kim.telematik / 123456789)
Die Übertragung wird mit Fehler "421 Service not available, closing transmission channel" beendet.
Die persönlichen Praxisdaten wurden anonymisiert, ist kein Fehler (max.musterarzt@tm.kim.telematik / 123456789)
Die Übertragung wird mit Fehler "421 Service not available, closing transmission channel" beendet.
2022-07-04 14:07:21,248 [DEBUG] [Zc1] connector.plugins.komle.configuration.ConfigurationUtils - Created POP3 username: max.musterarzt@tm.kim.telematik#mail.tm.kim.telematik:995#123456789#TurboMed#SERVER
2022-07-04 14:07:21,249 [DEBUG] [Zc1] connector.plugins.komle.ldap.LdapClient - Init LDAP client
2022-07-04 14:07:21,249 [DEBUG] [Zc1] connector.plugins.komle.configuration.ConfigurationUtils - Created SMTP username: max.musterarzt@tm.kim.telematik#mail.tm.kim.telematik:465#123456789#TurboMed#SERVER
2022-07-04 14:07:23,434 [DEBUG] [Zc1] connect.connector.plugins.komle.KomLePlugin - Send callback with result parameter:
2022-07-04 14:07:23,434 [DEBUG] [Zc1] connect.connector.plugins.komle.KomLePlugin -
parameter key: SMTP - parameter value: SUCCESS
parameter key: LDAP - parameter value: SUCCESS
parameter key: POP3 - parameter value: SUCCESS
2022-07-04 14:07:23,454 [DEBUG] [Zc1] connect.connector.plugins.komle.KomLePlugin - Customfunction sendMail called
2022-07-04 14:07:23,455 [DEBUG] [Zc1] connect.connector.plugins.komle.KomLePlugin -
parameter key: sender.system - parameter value: TURBOMED
parameter key: callid - parameter value: CF_PLUGIN|dppkvmail|handleConnectSendMailResult|289|
parameter key: notify.required - parameter value: false
parameter key: mail.text - parameter value: test
parameter key: confirm.required - parameter value: true
parameter key: ticontext - parameter value: [removed because it contains sensible data]
parameter key: assist::genericcustomfunction - parameter value: KomLePlugin.sendMail
parameter key: recipients - parameter value: max.musterarzt@tm.kim.telematik
parameter key: service - parameter value: KomLePlugin
parameter key: function - parameter value: sendMail
parameter key: mail.subject - parameter value: test 1407
parameter key: sender.system.version - parameter value: 22.2.2
parameter key: mail.type - parameter value: timail
parameter key: username - parameter value: max.musterarzt@tm.kim.telematik
2022-07-04 14:07:23,460 [DEBUG] [Zc1] connect.connector.plugins.komle.KomLePlugin - Sending mail.
2022-07-04 14:07:23,461 [DEBUG] [Zc1] connector.plugins.komle.configuration.ConfigurationUtils - Created SMTP username: max.musterarzt@tm.kim.telematik#mail.tm.kim.telematik:465#123456789#TurboMed#SERVER
2022-07-04 14:07:23,466 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG: setDebug: Jakarta Mail version 1.6.5
2022-07-04 14:07:23,466 [DEBUG] [Zc1] connector.plugins.komle.mail.SMTPMail - Sending mail.
2022-07-04 14:07:23,495 [DEBUG] [Zc1] connector.plugins.komle.mail.SMTPMail - Sending mail: TIMAIL
2022-07-04 14:07:23,509 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Oracle]
2022-07-04 14:07:23,509 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: need username and password for authentication
2022-07-04 14:07:23,510 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: protocolConnect returning false, host=Server, user=Admin, password=<null>
2022-07-04 14:07:23,510 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: useEhlo true, useAuth true
2022-07-04 14:07:23,510 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: trying to connect to host "Server", port 8465, isSSL true
2022-07-04 14:07:23,587 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - 220 KIM Clientmodul ESMTP
2022-07-04 14:07:23,587 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: connected to host "Server", port: 8465
2022-07-04 14:07:23,588 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - EHLO Server.PRAXIS.local
2022-07-04 14:07:23,589 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - 250-OK
2022-07-04 14:07:23,590 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - 250-SIZE 35882577
2022-07-04 14:07:23,591 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - 250-AUTH LOGIN PLAIN
2022-07-04 14:07:23,591 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - 250-8BITMIME
2022-07-04 14:07:23,592 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - 250-ENHANCEDSTATUSCODES
2022-07-04 14:07:23,593 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - 250 DSN
2022-07-04 14:07:23,593 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: Found extension "SIZE", arg "35882577"
2022-07-04 14:07:23,594 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: Found extension "AUTH", arg "LOGIN PLAIN"
2022-07-04 14:07:23,594 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: Found extension "8BITMIME", arg ""
2022-07-04 14:07:23,594 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: Found extension "ENHANCEDSTATUSCODES", arg ""
2022-07-04 14:07:23,594 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: Found extension "DSN", arg ""
2022-07-04 14:07:23,594 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: STARTTLS requested but already using SSL
2022-07-04 14:07:23,594 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: protocolConnect login, host=Server, user=max.musterarzt@tm.kim.telematik#mail.tm.kim.telematik:465#123456789#TurboMed#SERVER, password=<non-null>
2022-07-04 14:07:23,595 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: Attempt to authenticate using mechanisms: LOGIN PLAIN DIGEST-MD5 NTLM XOAUTH2
2022-07-04 14:07:23,595 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: Using mechanism LOGIN
2022-07-04 14:07:23,595 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: AUTH LOGIN command trace suppressed
2022-07-04 14:07:24,931 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: AUTH LOGIN succeeded
2022-07-04 14:07:24,932 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: use8bit false
2022-07-04 14:07:24,932 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - MAIL FROM:<max.musterarzt@tm.kim.telematik> RET=FULL
2022-07-04 14:07:25,080 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - 250 2.1.0 Ok
2022-07-04 14:07:25,080 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - RCPT TO:<max.musterarzt@tm.kim.telematik>
2022-07-04 14:07:25,236 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - 250 2.1.5 Ok
2022-07-04 14:07:25,236 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: Verified Addresses
2022-07-04 14:07:25,236 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: max.musterarzt@tm.kim.telematik
2022-07-04 14:07:25,236 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DATA
2022-07-04 14:07:25,237 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - 354 OK
2022-07-04 14:07:25,241 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - Return-Path: max.musterarzt@tm.kim.telematik
2022-07-04 14:07:25,241 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - Date: Mon, 4 Jul 2022 14:07:23 +0200 (CEST)
2022-07-04 14:07:25,241 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - From: max.musterarzt@tm.kim.telematik
2022-07-04 14:07:25,242 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - To: max.musterarzt@tm.kim.telematik
2022-07-04 14:07:25,242 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - Message-ID: <5536631.0.1656936443509@Server.PRAXIS.local>
2022-07-04 14:07:25,242 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - Subject: test 1407
2022-07-04 14:07:25,242 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - MIME-Version: 1.0
2022-07-04 14:07:25,242 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - Content-Type: text/plain; charset=UTF-8
2022-07-04 14:07:25,242 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - Content-Transfer-Encoding: 7bit
2022-07-04 14:07:25,243 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - Disposition-Notification-To: max.musterarzt@tm.kim.telematik
2022-07-04 14:07:25,243 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - X-KIM-Dienstkennung: eNachricht;Lieferung;V2.0
2022-07-04 14:07:25,243 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - X-KIM-Sendersystem: TURBOMED;22.2.2
2022-07-04 14:07:25,243 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - test
2022-07-04 14:07:25,243 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - .
2022-07-04 14:07:48,184 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - 421 Service not available, closing transmission channel
2022-07-04 14:07:48,185 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - DEBUG SMTP: got response code 421, with response: 421 Service not available, closing transmission channel
2022-07-04 14:07:48,185 [INFO ] [Zc1] com.cgm.connect.connector.ConnectorImpl - RSET
Moin joh316,
OK, das ist normal.
Habe ich auf dem Schirm ist aber in dem Fall nur sekundär, da beide SMTP-Proxy-Modele sich bei dieser Geschichte negativ auswirken könnten.
Jetzt bin ich etwas verwirrt.
Du nattest bereits schon am Standort A, warum?
Wenn ich das auch nur halbwegs richtig verstehe, dann musst du am Standort B natten und nicht am Standort A.
Im Netz des Standorts B wo auch der KVN-Connector hängt, funktioniert der SMTP Versand ja ohne Probleme, ist das korrekt?
Gruss Alex
Nein, der Eintrag kommt automatisch aller ca. 15 Sekunden.
OK, das ist normal.
Als Erinnerung: Standort A kein MTA, Standort B MTA
Habe ich auf dem Schirm ist aber in dem Fall nur sekundär, da beide SMTP-Proxy-Modele sich bei dieser Geschichte negativ auswirken könnten.
Mit Anlegen der Firewallregel für den Verkehr von Standort A nach KVN (Dienst beliebig) habe ich eine verknüpfte NAT Regel erstellt, die einzige Änderung, die ich dort vorgenommen habe ist:
Quelle: MASQJetzt bin ich etwas verwirrt.
Du nattest bereits schon am Standort A, warum?
Wenn ich das auch nur halbwegs richtig verstehe, dann musst du am Standort B natten und nicht am Standort A.
Im Netz des Standorts B wo auch der KVN-Connector hängt, funktioniert der SMTP Versand ja ohne Probleme, ist das korrekt?
Gruss Alex
Nein, das hast du falsch verstanden, bzw. ich habe unvollständig geschrieben: Ich natte am Standort B den Verkehr von Standort A nach KVN.
Im Netz des Standorts B wo auch der KVN-Connector hängt, funktioniert der SMTP Versand ja ohne Probleme, ist das korrekt?
Korrekt, die anderen Praxen, die Ihren Server im selben Netz haben, wo der Konnektor auch drin ist, können über KIM senden und empfangen, wobei der Verkehr ja am Standort B an der Sophos vorbei geht.
Moin Joh316,
OK, das hört sich schon besser an.
Interessant und wichtig, was genau meinst du damit?
Gruss Alex
Nein, das hast du falsch verstanden, bzw. ich habe unvollständig geschrieben: Ich natte am Standort B den Verkehr von Standort A nach KVN.
OK, das hört sich schon besser an.
wobei der Verkehr ja am Standort B an der Sophos vorbei geht.
Interessant und wichtig, was genau meinst du damit?
Gruss Alex
Zitat von @MysticFoxDE:
Nun, in dem Moment, wo der Server und der Konnektor im selben IP-Netz sind, erfolgt das Routing ja über den Switch und nicht über die Sophos. Letztlich geht nur der VPN-Verkehr von der Kocobox zur KV dann über die Sophos.wobei der Verkehr ja am Standort B an der Sophos vorbei geht.
Interessant und wichtig, was genau meinst du damit?Ergänzung:
Ein Kunde nutzt bei uns Outlook ohne Exchange Server. Dort funktioniert der SMTP Versand über Port 465 (In dem Fall Routing über die betroffene Sophos am Standort B) problemlos. Das hat dann allerdings nichts mit KIM zu tun. Der besagte Kunden-Server steht auch selbst am Standort B - aber in einem separierten Netz.
Moin Joh316,
Nicht ganz, das Routing geht normalerweise über das Standardgateway.
Ist die Kocobox etwa das Standardgateway in diesem Netz?
Sorry für die ganzen Fragen, aber wie ich oben schon erwähnt haben, kenne ich mich im Spezialbereich der Ärzte-IT nicht wirklich aus.
Gruss Alex
Nun, in dem Moment, wo der Server und der Konnektor im selben IP-Netz sind, erfolgt das Routing ja über den Switch und nicht über die Sophos.
Nicht ganz, das Routing geht normalerweise über das Standardgateway.
Letztlich geht nur der VPN-Verkehr von der Kocobox zur KV dann über die Sophos.
Ist die Kocobox etwa das Standardgateway in diesem Netz?
Sorry für die ganzen Fragen, aber wie ich oben schon erwähnt haben, kenne ich mich im Spezialbereich der Ärzte-IT nicht wirklich aus.
Gruss Alex
Die Kocobox ist nicht das Standard-Gateway, sondern die Sophos. Die Server am Standort B haben eine ständige Route drin, die alles in das KVN über die Kocobox leitet. Damit sollte die Sophos erstmal draußen sein.
Das ist falsch und ein Routingkonfig Fehler wenn die Server eine Route dorthin haben. Zumindestens ist es unsauber.
Die Sophos ist das zentrale routende Element im netz und diese MUSS eine statische Route auf die Zielnetze hinter der Kocobox haben via ihr als next Hop.
Endgeräte sollten in einem sauberen L3 Design niemals statische Routen haben. Aktiv routen sollen in einem netzwerk immer nur die Router und keinerlei Endgeräte.
Die Sophos ist das zentrale routende Element im netz und diese MUSS eine statische Route auf die Zielnetze hinter der Kocobox haben via ihr als next Hop.
Endgeräte sollten in einem sauberen L3 Design niemals statische Routen haben. Aktiv routen sollen in einem netzwerk immer nur die Router und keinerlei Endgeräte.
Moin Joh316,
so wie es Aqui schon geschrieben hat, das ist nix gut und die Sophos ist da keineswegs draussen, die routet und nattet sich da eher den 🐺ab. 😬
Melde mich später bin, bin gerade im Stress.
Gruss Alex
Die Kocobox ist nicht das Standard-Gateway, sondern die Sophos. Die Server am Standort B haben eine ständige Route drin, die alles in das KVN über die Kocobox leitet. Damit sollte die Sophos erstmal draußen sein.
so wie es Aqui schon geschrieben hat, das ist nix gut und die Sophos ist da keineswegs draussen, die routet und nattet sich da eher den 🐺ab. 😬
Melde mich später bin, bin gerade im Stress.
Gruss Alex
Zitat von @aqui:
Das ist falsch und ein Routingkonfig Fehler wenn die Server eine Route dorthin haben. Zumindestens ist es unsauber.
Die Sophos ist das zentrale routende Element im netz und diese MUSS eine statische Route auf die Zielnetze hinter der Kocobox haben via ihr als next Hop.
Endgeräte sollten in einem sauberen L3 Design niemals statische Routen haben. Aktiv routen sollen in einem netzwerk immer nur die Router und keinerlei Endgeräte.
Das ist falsch und ein Routingkonfig Fehler wenn die Server eine Route dorthin haben. Zumindestens ist es unsauber.
Die Sophos ist das zentrale routende Element im netz und diese MUSS eine statische Route auf die Zielnetze hinter der Kocobox haben via ihr als next Hop.
Endgeräte sollten in einem sauberen L3 Design niemals statische Routen haben. Aktiv routen sollen in einem netzwerk immer nur die Router und keinerlei Endgeräte.
Vielen Dank für den Hinweis. Habe am Server an Standort A nun die Route entfernt und in der Sophos an Standort A die Route ergänzt. Am Standort B gab es die Route zur Kocobox bereits
Standort A:
KV-Netz geht nun über IP der Sophos am Standort B
Standort B:
KV-Netz geht nun über IP des Konnektors an Standort B
Das Routing sieht in der Paketerfassung sauber aus. (Sah es auch vorher schon)
Aber ich sehe ein, dass die statische Route unschön ist.
Das Verhalten ist jedoch auch nach der Anpassung identisch - die Nachricht wird nicht verschickt. Selbe Fehlermeldungen.
Was ich aktuell nicht durchführen kann: An den Servern am Standort B die Routen zu entfernen und über das Standardgateway zur Kocobox zu routen. Das kann ich nur testen, wenn keiner arbeitet. Sollte tatsächlich der Versand nicht funktionieren, weil die Sophos dazwischen hängt, wäre das im Livebetrieb unschön.
Vielleicht hat ja noch jemand eine Idee, welche Einstellung an der Sophos dazu führen kann, dass die SMTP-Pakete an der Kocobox verworfen werden. Im Logfile der Kocobox kann ich sehen, dass die Pakete mit "Drop" markiert sind. (Bedeutet aber auch, dass die Pakete bis dort hin kommen)
Ein Turbomed Techniker sagte mir, das könne an E-Mail Inspektionen / SSL-Interception liegen.
Die SSL/TLS-Inspektion ist aber auf beiden Seiten ausgeschalten. Habe gestern testweise diese eingeschalten und eine Ausschlussregel definiert, dass die Pakete von Seite A nach Konnektor auf Seite B nicht entschlüsselt werden. Aber selbes Verhalten.
Zitat von @joh316:
Was ich aktuell nicht durchführen kann: An den Servern am Standort B die Routen zu entfernen und über das Standardgateway zur Kocobox zu routen. Das kann ich nur testen, wenn keiner arbeitet. Sollte tatsächlich der Versand nicht funktionieren, weil die Sophos dazwischen hängt, wäre das im Livebetrieb unschön.
Was ich aktuell nicht durchführen kann: An den Servern am Standort B die Routen zu entfernen und über das Standardgateway zur Kocobox zu routen. Das kann ich nur testen, wenn keiner arbeitet. Sollte tatsächlich der Versand nicht funktionieren, weil die Sophos dazwischen hängt, wäre das im Livebetrieb unschön.
Wenn du das Routing auf der XG sauber gesetzt hast und auch die entsprechende FW Regel (LAN to LAN) erstellt hast, dann sollte das eigentlich ohne Probleme gehen.
Vielleicht hat ja noch jemand eine Idee, welche Einstellung an der Sophos dazu führen kann, dass die SMTP-Pakete an der Kocobox verworfen werden. Im Logfile der Kocobox kann ich sehen, dass die Pakete mit "Drop" markiert sind. (Bedeutet aber auch, dass die Pakete bis dort hin kommen)
Ohh, das ist eine Interessante Info.
Das riecht irgendwie eher danach, als ob das NAT an der XG am Standort B nicht ganz richtig ist.
Ein Turbomed Techniker sagte mir, das könne an E-Mail Inspektionen / SSL-Interception liegen.
Die SSL/TLS-Inspektion ist aber auf beiden Seiten ausgeschalten. Habe gestern testweise diese eingeschalten und eine Ausschlussregel definiert, dass die Pakete von Seite A nach Konnektor auf Seite B nicht entschlüsselt werden. Aber selbes Verhalten.
Die SSL/TLS-Inspektion ist aber auf beiden Seiten ausgeschalten. Habe gestern testweise diese eingeschalten und eine Ausschlussregel definiert, dass die Pakete von Seite A nach Konnektor auf Seite B nicht entschlüsselt werden. Aber selbes Verhalten.
Deshalb habe ich dir davor ja auch die ganze Zeit wegen den MTA's die Löcher in den Bauch gefragt. 🤪
Also vielen Dank erstmal bis hierhin - ich bin nun im Urlaub.
Melde mich wieder, wenn ich zurück bin.
Melde mich wieder, wenn ich zurück bin.
Melde mich zurück.
Damit funkt zumindest schon mal kein Paketfilter der Sophos dazwischen. Gut zu wissen
Dabei werden die Quellpakete aus dem Netz von Standort A mit der IP der Sophos an Standort B maskiert. Sonst wird nichts verändert.
Danke nochmals für weitere Gedanken.
Zitat von @MysticFoxDE:
Wenn du das Routing auf der XG sauber gesetzt hast und auch die entsprechende FW Regel (LAN to LAN) erstellt hast, dann sollte das eigentlich ohne Probleme gehen.
Habe eben am Server am Standort B (Dort funktioniert KIM reibungslos) die statische Route entfernt und nutze nun das Routing ausschließlich über die Sophos an Standort B. Senden der KIM-Nachrichten funktioniert auch auf diesem Weg einwandfrei.Zitat von @joh316:
Was ich aktuell nicht durchführen kann: An den Servern am Standort B die Routen zu entfernen und über das Standardgateway zur Kocobox zu routen. Das kann ich nur testen, wenn keiner arbeitet. Sollte tatsächlich der Versand nicht funktionieren, weil die Sophos dazwischen hängt, wäre das im Livebetrieb unschön.
Was ich aktuell nicht durchführen kann: An den Servern am Standort B die Routen zu entfernen und über das Standardgateway zur Kocobox zu routen. Das kann ich nur testen, wenn keiner arbeitet. Sollte tatsächlich der Versand nicht funktionieren, weil die Sophos dazwischen hängt, wäre das im Livebetrieb unschön.
Wenn du das Routing auf der XG sauber gesetzt hast und auch die entsprechende FW Regel (LAN to LAN) erstellt hast, dann sollte das eigentlich ohne Probleme gehen.
Damit funkt zumindest schon mal kein Paketfilter der Sophos dazwischen. Gut zu wissen
Ohh, das ist eine Interessante Info.
Das riecht irgendwie eher danach, als ob das NAT an der XG am Standort B nicht ganz richtig ist.
Das NAT an der XG an Standort B greift für den Fall, dass ein Paket von Standort A nach KV-Netz will:Das riecht irgendwie eher danach, als ob das NAT an der XG am Standort B nicht ganz richtig ist.
Dabei werden die Quellpakete aus dem Netz von Standort A mit der IP der Sophos an Standort B maskiert. Sonst wird nichts verändert.
Danke nochmals für weitere Gedanken.
Das Problem konnten wir mit dem TI Level 2 Support von CGM nun endlich lösen.
Ursache war: CGM hatte uns vor Jahren an der KoCoBox für LAN eine MTU von 1300 eingestellt.
Diese MTU war zu klein für dieses Vorhaben und musste auf 1400 gestellt werden.
Seitdem funktioniert KIM rein und raus!
Danke trotzdem allen, die hier versucht hatten, eine Lösung zu finden.
Ursache war: CGM hatte uns vor Jahren an der KoCoBox für LAN eine MTU von 1300 eingestellt.
Diese MTU war zu klein für dieses Vorhaben und musste auf 1400 gestellt werden.
Seitdem funktioniert KIM rein und raus!
Danke trotzdem allen, die hier versucht hatten, eine Lösung zu finden.
2
Vielen Dank, bei uns lag es auch an der MTU der KoCoBox. 1300 musste ja damals einstellt werden, wenn die Updates nicht funktionieren. Vielleicht ist das ja inzwischen behoben und geht auch mit 1400.
