Lancom DSL/I-10 Verbindungsabbruch bei Terminalserver

[UweB]

Hallo,

ich habe folgendes Problem:

Ein Terminalserver ist über ein Lancom DSL/I-10 Office (FW: 3.58.0006) per DSL und Dyndns von aussen erreichbar. Leider bricht die Verbindung zu diesem Terminalserver teilweise alle paar Minuten ab. Laut Lanmonitor wurde die Verbindung zu DSL aber nicht getrennt, sondern bestand die ganze Zeit über. Die Telekom hat die Leitung gemessen, angeblich ist hier alles in Ordnung. Am Terminalserver liegt es nicht, bei Verbindungen auf einen zweiten Terminalserver am gleichen Standort tritt dasselbe Problem auf. An den Gegenstellen liegt es auch nicht, das Problem tritt bei der Verbindung von allen Gegenstellen auf.

In der Statistik des LC stehen folgende Fehler:
TCP-WAN-service-errors: 6871
LAN-Stack-Fehler: 15357

Ich habe trotz der Aussage der Telekom die DSL-Leitung in Verdacht. Welchen Trace könnte ich denn laufen lassen, um das Problem einzugrenzen?

Bin für jeden Tip dankbar.

Viele Grüße
Uwe

[UweB]

Hallo,

ich habe mal einen Trace auf IP-Router und TCP laufen lassen und als Anlage beigefügt.

Der Terminalserver mit dem gearbeitet werden soll, hat die 192.168.3.2 und die Verbindung kommt über die Gegenstelle T-ONLINE.

Im LC ist DHCP auf "Weiterleitung" eingerichtet zum Domänencontroller 192.168.3.1, der auch DNS- und DHCP-Server ist.

Nach ca. 6 Minuten kommt dann der Abbruch der Terminalserververbindung, im Protokoll stehen DHCPDISCOVER- und DHCPOFFER-Meldungen. Vielleicht liegt hier der Hund begraben?

Viele Grüße
Uwe

[backslash]

Hi UweB

das Problem ist eindeutig:

das Letze Paket was zum Terminal-Server übertagen wurde ist das hier:

Code: Alles auswählen

[IP-router] 2008/04/03 13:41:48,480
IP-Router Rx (T-ONLINE):
DstIP: 192.168.3.2, SrcIP: 91.17.205.68  DSCP/TOS: 0x00
Prot.: TCP (6)  DstPort: 3389, SrcPort: 46406, Flags: A
Route: LAN Tx

das nächste, das übertragen werden soll ist das hier:

Code: Alles auswählen

[IP-router] 2008/04/03 13:42:54,110
IP-Router Rx (T-ONLINE):
DstIP: 192.168.3.2, SrcIP: 91.17.205.68  DSCP/TOS: 0x00
Prot.: TCP (6)  DstPort: 3389, SrcPort: 46406, Flags: PA
Filter (Port)

Und das wird von der Firewall zurückgewiesen. Das kann nun mehrere Ursachen haben. Am einfachsten schaltest du mal den Firewall-Trace an...

Abhilfe könnte z.B. eine Firewallregel bringen, mit der die Zustandsprüfung für den Terminalserver deaktiviert wird:

Code: Alles auswählen

Quelle: Alle Stationen
Ziel:   IP-Adresse des Terminal-Servers
Aktion: übertragen

[ ] Diese Verbindung hält Verbindungszustände nach

ggf. hilft es auch unter Firewall/Qos -> Allgemein die Sitzungs-Wiederherstellung auch auf der Defaultroute zuzulassen

Gruß
Backslash

[UweB]

Hi Backslash,

vielen Dank für die schnelle Hilfe. Ich habe mal einen Firewall-Trace mitlaufen lassen, da steht folgendes drin:

[Firewall] 2008/04/03 15:26:20,150
Paket matched rule ALLOW_RDP
DstIP: 192.168.3.2, SrcIP: 91.17.205.68 DSCP/TOS: 0x00
Prot.: TCP (6) DstPort: 3389, SrcPort: 51935, Flags: PA

packet for unknown TCP session, session reovery denied on default route,
packet dropped

Kann ich den Ziel-Port 51935 gefahrlos in der Firewall für die Regel Allow_RDP erlauben, dann ist das Problemchen vielleicht behoben? Konnte in Google nichts vernünftiges über diesen Port finden.

Viele Grüße
Uwe

[/quote]

[backslash]

Hi UweB,

die Meldung sagt doch schon was los ist:

session reovery denied on default route

also:

unter Firewall/Qos -> Allgemein die Sitzungs-Wiederherstellung auf immer erlaubt stellen

Kann ich den Ziel-Port 51935 gefahrlos in der Firewall für die Regel Allow_RDP erlauben

51935 ist nicht der Ziel-, sondern der Quellport des Pakets und der ist auch schon erlaubt, denn sonst würde nicht die Regel "ALLOW_RDP" matchen...

Konnte in Google nichts vernünftiges über diesen Port finden

das ist ja auch ein frei gewählter Port des Clients, der sich bei jeder Session ändert...

Gruß
Backslash

[UweB]

Hi Backslash,

da hab ich wohl Quell- und Zielport verwechselt, wer lesen kann ist halt echt im Vorteil

Ich habe "Sitzungs-Wiederherstellung" auf "immer erlaubt" gestellt und seitdem scheint alles wie gewünscht zu funktionieren.

Vielen Dank nochmal für die kompetente und vor allem auch schnelle Hilfe.

UweB