Problem: aus e. Netz mit LINUX-Firewall soll HBCI betrieben werden mit Chipkarte als Sicherheitsmedium. Als Client wird SFirm unter W2k benutzt; leider bricht die Verbindung nach ein paar Paketen ab;
- die Verbindung bricht ab, egal auf welcher Maschine im Netz die Software gestartet wird;
- Das Netz ist per TKOM-DSL an das Internet angeschlossen;
- HBCI mit Sicherheitsdiskette funktioniert problemlos, egal welche Maschine, Software (SFirm, EFIX, MoneyPlex, StarMoney), Betriebssystem (W32, Linux), bei HBCI mit Chipkarte bricht die Verbindung bei allen Varianten an derselben Stelle ab (es müsste theoretisch wieder ein Paket von der Bank kommen, lt. HBCI-Zentrale wird das Protokoll fehlerfrei abgearbeitet, sie schicken angeblich die Daten, die nie ankommen).
- Client, Chipkarte und -leser funktionieren nachweislich (in anderen Netz, kein DSL) ohne Probleme
- bei einem Windowsclient direkt an das DSL-Modem angeschlossen hat wieder alles funktioniert.


Der Verkehr wurde mit tcpdump -i any host x.x.x.x überwacht, da es TCP ist, müss
en alle Pakete bestätigt werden, ein 'heimlicher' Wechsel von Port oder Serverhost ist nicht möglich; jedes mitgeschnittene Paket taucht dreimal auf: vo
m Clienthost an die Firewall, vom Clienthost an den Zielhost, von der Firewall an den Zielhost, auch wenn man länger wartet kommt vom Bankrechner kein Datenpake
t mehr an, SFirm bricht nach Ablauf des Timeouts mit einer Fehlermeldung ab.
Auf der Firewall habe ich verschiedene Varianten durchprobiert ohne Änderung des
Verhaltens: - Portforwarding (Pakete vom Bankrechner werden direkt durchgeschalten zum SFirm Rechner)
- normales Forwarding mit Statefull Inspection und Masquerading für Port 3000 (Hin- und Rückkanal)
- völliges Freischalten aller Datenpakete vom Clientrechner.

Da HBCI mit Diskette in allen Fällen funktioniert, gehe ich davon aus,daß, wie auch in anderen betreuten Netzen, das normale Forwarding für Pakete zum Port 3000 des Bankrechners ausreichend ist.

Was ist, protokolltechnisch, der Unterschied zwischen HBCI mit Chipkarte und Diskette, wie kann sich das auswirken (unterschiedlich große Datenpakete?); die MTU bei DSL ist 1492, allerdings überschreitet keines der Pakete zu Beginn der Kommunikation 500 Byte, also kommt ein Fragmentierungsproblem auch nicht in Frage.

Die Bank sieht den Fehler im Netzwerk, resp. der Firewall, ich kann allerdings, aufgrund der Verschlüsselung, den Inhalt der Pakete nicht untersuchen und so gegf. das Gegenteil beweisen.

Ist irgendwem dieses seltsame Verhalten schon einmal begegnet?

Danke

Dies hab ich in einem anderen Forum entdeckt. Vielleicht hilft es, das Problem etwas einzukreisen:

Also bei der SI treten auch diverse Probleme in Verbindung mit Chipkarte und Sammlern auf. Seltsamerweise aber nur bei einem Zugang über T-DSL. Nach Änderung des MTU läuft es aber. Hier eine kurze Anleitung...

Das DSL-Protokoll kann 1492 MTUs (= maximum transfer unit = max. Größe der IP-Pakete) übertragen. Im normalen Netzwerk (Ethernet) wird jedoch mit Paketgrößen von 1500 gearbeitet. Schickt nun der PC des Kunden ein Paket mit eine Größe von 1500, so gehen jedoch nur 1492 MTUs auf die Reise ins Internet.

Um den richtigen MTU-Wert herauszufinden, öffnen Sie die MS-Eingabeaufforderung (cmd.exe oder command.exe) und geben dort folgendes ein:

ping -f -l 1492 xxxx.s-hbci.de (DNS für Institut)

Erhalten Sie die Meldung: "Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.", ist die Paketgröße noch zu hoch.

Versuchen Sie es erneut mit einer geringeren Paketgröße, z.B. 1432:

ping -f -l 1432 xxxx.s-hbci.de

Haben Sie hier Erfolg, sollte die Meldung "Zeitüberschreitung der Anforderung (Timeout)" erscheinen. (Ich selbst habe die Paketgröße von 1412 im Einsatz).

Laden Sie sich das Programm DFÜ-Speed herunter und installieren Sie es: http://www.das-download-archiv.de/download.php?id=548

Rufen Sie das Programm auf, wählen Sie unten rechts "DSL Optim." und ändern Sie obenlinks den MaxMTU-Wert von 1492 auf Ihre neue MTU-Paketgröße (z.B. 1432) ab:

Klicken Sie auf OK und starten Sie den Rechner erneut.

Öffnen Sie zuerst eine beliebige Internetadresse (z. B. www.gmx.de) um festzustellen, dass die Internetverbindung auch korrekt funktioniert.