Routing-Problem?

joh316
Goto Top
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.

Content-Key: 2897703651

Url: https://administrator.de/contentid/2897703651

Ausgedruckt am: 01.07.2022 um 18:07 Uhr

Mitglied: altmetaller
altmetaller 25.05.2022 um 22:51:58 Uhr
Goto Top
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
Mitglied: joh316
joh316 26.05.2022 um 05:47:13 Uhr
Goto Top
Vielen Dank für deine Antwort. Ja. Die Route ist ebenfalls da.
Mitglied: MysticFoxDE
MysticFoxDE 26.05.2022 aktualisiert um 07:28:32 Uhr
Goto Top
Moin Joh,

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.

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

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
Mitglied: cykes
cykes 26.05.2022 um 07:52:49 Uhr
Goto Top
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
Mitglied: MysticFoxDE
MysticFoxDE 26.05.2022 aktualisiert um 08:23:00 Uhr
Goto Top
Moin 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?

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
Mitglied: cykes
cykes 26.05.2022 um 08:55:01 Uhr
Goto Top
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. 😁

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
Mitglied: aqui
aqui 26.05.2022 aktualisiert um 10:40:36 Uhr
Goto Top
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... face-sad
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.
Mitglied: MysticFoxDE
MysticFoxDE 26.05.2022 um 14:05:05 Uhr
Goto Top
Moin Aqui,

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... face-sad

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?!

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
Mitglied: joh316
joh316 27.05.2022 um 22:51:43 Uhr
Goto Top
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.
Mitglied: MysticFoxDE
MysticFoxDE 28.05.2022 um 08:41:31 Uhr
Goto Top
Moin Cykes,

In aller Kürze geht es konkret tatsächlich um eine Arztpraxis.

der Punt geht an dich. 😉

Gruss Alex
Mitglied: MysticFoxDE
MysticFoxDE 28.05.2022 um 08:48:29 Uhr
Goto Top
Moin Joh316,

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.

😮 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
Mitglied: cykes
cykes 28.05.2022 aktualisiert um 09:25:20 Uhr
Goto Top
Wobei Du zu
Zitat von @MysticFoxDE:
[...]KIL[...]
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) 😉
@Cykes
Sorry, das ist glaube ich doch eher deine Spezialität.
Mal schauen, was wir so ungesehen hinbekommen, CGM TurboMed hatte ich bisher auch noch nicht unter den Fingern.

Gruß

cykes
Mitglied: aqui
aqui 28.05.2022 um 11:12:10 Uhr
Goto Top
Bis IPSec steht die VPN.
Ägypten?? Was soll uns dieser kryptische Satz sagen?? Mal abgesehen davon das das VPN sächlich ist...
Mitglied: cykes
cykes 28.05.2022 um 13:19:45 Uhr
Goto Top
@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.
Mitglied: jktz84
jktz84 28.05.2022 aktualisiert um 23:16:02 Uhr
Goto Top
Zitat von @joh316:
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.
Mitglied: MysticFoxDE
MysticFoxDE 29.05.2022 um 07:32:26 Uhr
Goto Top
Moin Cykes,

Zitat von @MysticFoxDE:
[...]KIL[...]
jetzt hättest was schlaues schreiben können - das war glaub nur ein Tippfehler und KIM war gemeint. 🤣
kil

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. 🤪

@Cykes
Sorry, das ist glaube ich doch eher deine Spezialität.
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
Mitglied: joh316
joh316 30.05.2022 um 12:03:10 Uhr
Goto Top
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.

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.
Mitglied: joh316
joh316 30.05.2022 um 12:08:01 Uhr
Goto Top
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:
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.
Mitglied: jktz84
jktz84 30.05.2022 um 12:30:54 Uhr
Goto Top
Zitat von @joh316:
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.
Mitglied: joh316
joh316 30.05.2022 um 14:25:41 Uhr
Goto Top
Zitat von @MysticFoxDE:
Der Medizinserver ist dann wohl der SMTP Client, korrekt?
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?
Die Mail wird an ein Ziel innerhalb des KV-Netzes verschickt.
Die Sophos an Standort B läuft im MTA-Modus (Liegt hier vielleicht eine Besonderheit?)
Mitglied: MysticFoxDE
MysticFoxDE 30.05.2022 um 19:34:23 Uhr
Goto Top
Moin Joh316,

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.
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
Mitglied: joh316
joh316 31.05.2022 um 07:57:23 Uhr
Goto Top
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.
Mitglied: MysticFoxDE
MysticFoxDE 31.05.2022 aktualisiert um 08:20:01 Uhr
Goto Top
Moin Joh316,

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.

xg-netzwerkzone-smtp-relay

P.S.P.S.
Ähm, hast du auf der XG SD-WAN in Betrieb?
Mitglied: joh316
joh316 31.05.2022 um 11:17:07 Uhr
Goto Top
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...

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.
Mitglied: MysticFoxDE
MysticFoxDE 31.05.2022 um 11:41:21 Uhr
Goto Top
Moin Joh316,

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
Mitglied: joh316
joh316 31.05.2022 um 12:27:25 Uhr
Goto Top
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.

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:
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 ;)
Mitglied: MysticFoxDE
MysticFoxDE 01.06.2022 um 06:41:37 Uhr
Goto Top
Moin Joh,

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.

😬, 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
Mitglied: joh316
joh316 03.06.2022 um 13:57:28 Uhr
Goto Top
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...

Zitat von @MysticFoxDE:
Sind die IP Adressen am Standort B, vom KVN Betreiber vorgegeben?
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.
Mitglied: MysticFoxDE
MysticFoxDE 03.06.2022 um 20:20:57 Uhr
Goto Top
Moin 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...

ä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. 😎

Zitat von @MysticFoxDE:
Sind die IP Adressen am Standort B, vom KVN Betreiber vorgegeben?
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
Mitglied: jktz84
jktz84 04.06.2022 aktualisiert um 12:34:55 Uhr
Goto Top
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...

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.
Mitglied: cykes
cykes 04.06.2022 um 13:31:22 Uhr
Goto Top
Moin,

ich misch mich auch mal wieder ein face-wink Ich glaube nicht, dass es dem Clientmodul gefällt, wenn da noch ein Mailproxy auf dem Weg
dazwischengeschaltet ist.

Gruß

cykes
Mitglied: cykes
cykes 04.06.2022 um 16:25:43 Uhr
Goto Top
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 face-wink Ich glaube, das Konzept versteht nicht mal die Gematik und die Umsetzung noch viel weniger face-wink
Mitglied: joh316
joh316 09.06.2022 um 11:44:26 Uhr
Goto Top
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.
Mitglied: aqui
aqui 27.06.2022 um 15:01:32 Uhr
Goto Top
Wenn es das denn nun war bitte dann auch deinen Thread hier als erledigt schliessen!
Mitglied: joh316
joh316 27.06.2022 um 17:26:24 Uhr
Goto Top
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.
Mitglied: aqui
aqui 27.06.2022 um 18:55:56 Uhr
Goto Top
Der Fehler ist dann meistens eine Firewall oder lokale Firewall die einseitig den Traffic Flow filtert oder blockt.
Mitglied: joh316
joh316 01.07.2022 aktualisiert um 10:24:06 Uhr
Goto Top
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.

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.
senden
Mitglied: aqui
aqui 01.07.2022 um 11:34:54 Uhr
Goto Top
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.
Mitglied: joh316
joh316 01.07.2022 um 11:42:12 Uhr
Goto Top
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.
Mitglied: aqui
aqui 01.07.2022 um 11:52:16 Uhr
Goto Top
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.
Mitglied: MysticFoxDE
MysticFoxDE 01.07.2022 um 12:20:09 Uhr
Goto Top
Moin joh316,

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
Mitglied: joh316
joh316 01.07.2022 um 12:40:21 Uhr
Goto Top
Zitat von @aqui
OK, wenn man das Routing wirklich sicherstellen kann dann musst du mit dem Wireshark ran.
OK.

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?

Die SSL/TLS Inspection Engine ist auf beiden Seiten ausgeschalten.
Mitglied: MysticFoxDE
MysticFoxDE 01.07.2022 um 18:56:43 Uhr
Goto Top
Moin joh316,

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